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

[Sebastian Kügler]

Hi Jos,

On Wednesday, January 30, 2013 10:47:06 Jos Poortvliet wrote:
> 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...

Do you have a bugreport for that? We had a late Nepomuk merge in that area for 
the 4.10 release, and we need to know about regressions it might have caused.

> 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?

So you look which data you already have, throw it away, read it in again. 
Gain: Zero, I suppose.

> 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).

Vishesh has just published a tool which cleans up the Nepomuk database. I 
don't know to what extent that helps for any given problem, however.

> 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!

I don't think anybody on this list suggested that. User A telling User B to 
remedy his problems with a big bloody axe is not something we can do a lot 
about, other than telling people to not tell others to nuke all their 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...

I'm all for better solutions as well. Why has nobody else thought of this 
before? :D

Seriously, I don't think the PIMsters, Nepomuksters, or anybody else is 
dismissing a solution that would solve all the problems. The way to make a 
piece of software reliable is exactly to fix all those cornercase, not "accept 
them". That fixing is called maturing, and there's really no way around it. 
However cruel that might be.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
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/