Is KMail excruciatingly slow by design?

[dmeyer]

Background on the Strigi expunge... http://vhanda.in/blog/2012/11/nepomuk-without-strigi/

However, take a look at the dependecy list for KMail. It includes both libstreams0 and libstreamanalyzer0. So while Nepomuk appears to be using its own internal indexer for files, it appears that KMail still wants to use Strigi. Difficult to tell without actually diving into the source code...

I removed strigi on my side and kmail2 seems to be unaffected. I wonder if its just legacy cruft that hasn't been removed yet. Still, I'm cautious of recommending it outright.

[oshunluvr]

libstreams0 and libstreamanalyzer0 had a lot of dependencies on my system so I didn't remove them. I didn't get any PC time yesterday so I don't know how it's working at the moment. I'll report later tonight.

[SteveRiley]

I removed strigi on my side and kmail2 seems to be unaffected. I wonder if its just legacy cruft that hasn't been removed yet. Still, I'm cautious of recommending it outright.

You can remove the strigi-client, strigi-daemon, and strigi-utils packages, because Nepomuk no longer uses them. For file indexing, Nepomuk ditched Strigi and now relies on a simpler file-based mechanism as described in the blog post I referenced.

KMail is different...it still uses the Strigi streams libraries for message indexing:

steve@t520:~$ [B]apt-cache depends kmail[/B]
kmail
. . .
  Depends: libstreamanalyzer0
  Depends: libstreams0
. . .

libstreams0 and libstreamanalyzer0 had a lot of dependencies on my system so I didn't remove them. I didn't get any PC time yesterday so I don't know how it's working at the moment. I'll report later tonight.

You can't yet without breaking KDE. Other elements of KDE also use the Strigi streams libraries -- the core KDE Workspace binaries and libkio at least.

[oshunluvr]

Kmail is definitely faster than when I started this thread. I can live with it. However, removing strigi (excepting the two libs noted above) has made no difference. nepo-puke is still crashing.

[SteveRiley]

Today's 4.11 beta announcement has some relevant bits...

Faster Nepomuk indexing—The Nepomuk semantic engine received massive performance optimizations (e.g., reading data is 6 or more times faster). Indexing happens in two stages: the first stage retrieves general information (such as file type and name) immediately; additional information like MP3 tags, author information and similar is extracted in a second, somehow slower stage. Metadata display is now much faster. In addition, the Nepomuk backup and restore system was improved. The system also got new indexers for documents like odt or docx.

Kontact improvements—Kontact got a faster indexer for its PIM data with improvements to Nepomuk, and a new theme editor for email headers. The way it handles email images now allows it to resize pictures on the fly. The whole KDE PIM suite got a lot of bug fixes, such as the way it deals with Google Calender resources. The PIM Import Wizard allows users to import settings and data for Trojita (the Qt IMAP email client) and all other importers were improved as well.

[blackpaw]

Using 4.11 from trunk here, kontact etc all working well - google imap, calendar, contacts.

However nepomuk is disabled because it continually crashes on me. The dev doesn't seem interested in looking at the bug report.

[oshunluvr]

Using 4.11 from trunk here, kontact etc all working well - google imap, calendar, contacts.

However nepomuk is disabled because it continually crashes on me. The dev doesn't seem interested in looking at the bug report.

Sounds like the dev initially doing knetworkmanager. It worked on his machine, so there weren't any bugs...

[blackpaw]

Now file indexing is shot too.

The nepomuk DB seems to be flaky as h*ll. Tagging and rating is utterly pointless, you'll just lose it on the next db screwup. But at least it doesn't hog all my CPU time now.

OTOH, just for the hell of it I tried out Thunderbird and trojita with my gmail account. Thunderbird was fugly, but worked well. Surprisngly Trojita was quite slow. Both of them were missing features that I *really* like in Kontact - Smart looks, smooth UI, well integrated encryption, calendar and address book.

And for the record - kmail with offline gmail is really fast for me. Thats with a *lot* of emails. I've seen the blockign calls and hangs in the past, but 4.10.3+ has been really good for me.

[dmeyer]

I'm officially of the opinion that I am the only person who has a great experience with Akonadi, Kontact (including all its components), and Nepomuk. I haven't has issues since 4.9. You guys might need to try a fresh install sometime, because I never run into this crap (though don't know if being on openSUSE affects my experience). My Kubuntu dev VM isn't really used for my day to day work.

[claydoh]

I'm officially of the opinion that I am the only person who has a great experience with Akonadi, Kontact (including all its components), and Nepomuk. I haven't has issues since 4.9. You guys might need to try a fresh install sometime, because I never run into this crap (though don't know if being on openSUSE affects my experience). My Kubuntu dev VM isn't really used for my day to day work.

Nope, add me to the list. The initial move to kmail2 was a pain for importing/upgrading, but 4.9 onward it has been great for me. I don't think that this is distro-specific, thank goodness

[blackpaw]

Do both of you use the search facility - the search dlg, not the quick filter. Does it work?


I regularly do clean installs.

OTOH I do build nepomuk & akonadi from master, so some breakage is to be expected.

OTOH2, the reason I do so is to help with testing, but also because I seem to regulrary receive/generate emails that crash nepomuk and the only way to resolve that is from source.

[SteveRiley]

The only problem KMail causes for me is its propensity to lose Internet connection. It'll go check mail, and simply hang. I used to stop and restart Akonadi to fix this. I found a better way: click the blue arrow in the status bar and then click the do-not-enter circle. KMail will force a reconnection.

Oh, and I've switched the backend from MySQL to SQLite; that also seems to lessen the disconnects.

[woodsmoke]

To answer the OP.

NO.

Kmail/Akonadai/Nepomuk/YOUR HARDWARE/is/a/complex/situation/which/can/be/optimized/but/////

since "slow" is an affective domain situation.... only the person perceiving what is going on in the system can determine to his/her satisfaction if "slow" has been voided.

woodsmoke

woodsmoke