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

Sat Feb 2 18:17:40 GMT 2013

On Thursday 31 January 2013 23:23:17 Sebastian Kügler wrote:
> 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.
It doesn't happen after I updated to openSUSE Factory - but it was a known 
issue caused by the Activity manager interacting with dbus.

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

Considering the removing of legacy data, empty tags, duplicate tags, 
duplicate file metadata, duplicate icons and other cruft the Nepomuk Cleaner 
is spending hours on removing from my nepomuk database, I'm guessing there 
is a slightly above-zero gain to be had.

I'm quite happy with the nepomuk cleaner: it has led to a HUGE speed 
increase in KMail, so much that instead of opening all folders I regularly 
use in tabs I can now just open them on demand, without having to wait well 
over a minute per folder for them to open.

Thanks, Vishesh, and yes, I think it's a good idea to find out if we can 
somehow, not too intrusively, run this upon a upgrade to a newer version of 
Nepomuk.

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

A lot ;-)

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

It is the recommendation you'll find on lots of forums and how-to's. Most 
people experiencing issues with their KDE software don't ask here (and that 
is a good thing).

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

Sure, and I stuck with KDE PIM because I understand that very well. But it 
is clear that 'old' data in the database can cause issues and I'm quite 
happy with the nepomuk cleaner helping with that. I'd even recommend it to 
all users upgrading to SC 4.10, might be an idea to add this to our release 
announcement. At the very least it should be mentioned in the section about 
Nepomuk that it is recommended to run this tool at least on upgrade or 
something...

So, I just committed that to svn (also pointing to Vishesh's blog). Feel 
free to check for mistakes.

Hugs,
Jos

> Cheers,
-------------- 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/20130202/b3019560/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/