[Kde-pim] Did we reintroduce some performance issues with KDE 4.10?
Del
delonly at gmail.com
Mon Feb 4 18:37:42 GMT 2013
On Monday, February 04, 2013 02:33:57 PM Anne Wilson wrote:
> A delay of that sort, without adequate warning, will cause panic,
> aborted upgrades, and a lot of problems. Instead, I would recommend
> giving maximum publicity, especially on the download pages, to the
> fact that the cleaning is recommended prior to starting the upgrade,
> but must be allowed several hours to run. I'd even recommend that
> it's run overnight, if that's possible.
>
> Incidentally, from which version of KDE is the cleaner available?
>
> Anne
Not sure I understand the issue(s) correctly, but here it goes with my five
cents. From my reading of the thread there may be two issues at play (or maybe
not). Vishesh indicated that Jos's problems could be caused by a bug he is
trying to catch in activity manager, if successful that could for all I know
reduce the immediate need for nepomukcleaner. However, apart from bugs it
sounds like legacy data in Nepomuk is slowing Nepomuk down (please correct me
if I am wrong), and I assume that is addressed by the nepomukcleaner.
Moreover, Vishesh reports that the nepomukcleaner needs about 20 hours on his
set-up to complete. It is also my impression that an alternative to the
nepomukcleaner is to delete all nepomuk data, and redo the indexing,i.e., like
starting with a fresh install.
I think the last option (starting fresh with Nepomuk) would be the preferred
option in the majority of cases, as I assume few people put anyting but the
automatic indexing in Nepomuk today (this will hopefully change once Nepomuk
matures). Moreover, I guess re-genereating index from scratch will be much
faster than using the nepomukcleaner. Especially due to the improvements
Vishesh made to Nepomuk for 4.10. Maybe you can shed some light on this
Vishesh, how long do you think it would take on your set-up to delete Nepomuk
data, and then run the indexing from scratch (of course with the draw-back of
losing any data in Nepomuk that is not produced by the automatic indexing)?
I also think it makes sense to envision how an upgrade to KDE 4.10 or later
will happen for the vast majority of users. I belive that would be through a
distribution upgrade (please correct me if you have reason to believe that a
major proportion of users compile themselves, or in other ways install outside
of their distributions releases). I believe the appropriate action can be
determined at each distribution, also the distributions should be able to
automatically provide a dialogue for users upgrading, where users can be
warned and even themselves choose what they want to do. If so, it may be
sufficient to have a brief dialogue with the largest distributions for KDE
(OpenSuse, Kubuntu and Fedora comes to mind) on how they would like it
handled. Maybe providing nepomukceaner would be all they wanted, or maybe we
should provide a simple dialogue too (providing the basic choices on actions
to take for Nepomuk), a simple Qt mock-up should be feasible without much
effort.
In any case, I think it is important that we treat this issue carefully.
Vishesh has done a fantastic job, and Nepomuk is finally coming together
nicely. This is not the time for bad publicity.
Cheers,
Del
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list