[Kde-pim] Did we reintroduce some performance issues with KDE 4.10?

[Jos Poortvliet]

On Monday 28 January 2013 19:31:10 Jure Repinc wrote:
> Georg C. F. Greve wrote:
> > For me, virtuoso never drops under 100%, and after a day of operation
> > and even after akonadi restart, virtuoso can be at 350% CPU even when
> > Kontact isn't even running. Is this a local installation issue (and I
> > should just delete all accounts, and re-configure everything) or are
> > others experiencing similar behaviour?
> 
> Even though I have e-mail indexing disabled in Nepomuk settings I still
> get 100% CPU from virtuoso-t when displaying some e-mails. Especialy
> those comming from LinkedIn. I reported a bug about this some time ago:
> https://bugs.kde.org/show_bug.cgi?id=311064

Could be a virtuoso/Nepomuk thing. Since a few days I have dolphin hang on 
me when I do a right-click in a folder, until a timeout somewhere - it is 
definitely Nepomuk related as KMail is unable to show me any emails while 
Dolphin is hanging...

Of course, on a 'fresh' system I have no such issues. Problem is that we 
can't simply tell our users "clean the database and start over" whenever 
there is a problem, unless we create some kind of "problem solving wizard" 
which gives a graphical (and hopefully non-destructive for stored data) way 
of cleaning the index(es), restoring performance and stability.

So either, on an upgrade to a major new version of KDE PIM, we make sure the 
Nepomuk email database is cleaned and re-indexed, or we even go as far as to 
let Nepomuk remove all data it can extract from the filesystem upon a major 
upgrade and re-index that all again. Vishes, you listening? Do you think 
that makes sense?

I think users are far more forgiven to have to deal with Nepomuk re-indexing 
their data upon an upgrade of their distribution or KDE packages than having 
the weird kind of issues these complex inter-dependencies seem to create 
sometimes with no easy way to deal with (for a common user).

Note that the 'average user' often is advised to simply remove  ~/.kde4 when 
confronted with such inexplicable behavior, which is a rather destructive 
way of dealing with the issues we have. Worse, even going nuclear like this 
doesn't remove the Akonadi data as that's in the ~/.local folder so at least 
some problems persist after removing all settings and much private data!

Honestly, I think that it might be time to give up on trying to fix all 
corner cases and just accept that this technology is so complicated, weird 
and unpredictable errors will crop up. It might be time to find solutions to 
this which do not require our users to nuke all their personal settings and 
loose data...

hugs,
Jos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130130/688ffb85/attachment.sig>
-------------- next part --------------
_______________________________________________
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/