[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