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

[Vishesh Handa]

On Wed, Jan 30, 2013 at 3:17 PM, Jos Poortvliet <jos at opensuse.org> 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...
>

This seems to be related to the Activity Manager. I've been trying to debug
it, and it seems that the ActivityManager has some synchronous dbus calls.


>
> 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've been thinking along the same lines to a certain extent.

For 4.10, I've released a new application called 'nepomukcleaner' which
cleans up invalid/legacy/duplicate data in the Nepomuk DB. For 4.11, I'm
going to spruce it up and make running it mandatory.

( Yes, I need to blog about it, I'm writing the blog post right now )


>
> 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
> _______________________________________________
> 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/
>



-- 
Vishesh Handa
_______________________________________________
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/