[kdepim-users] Tbird versus Kmail, performance

[René J.V. Bertin]

On Saturday November 15 2014 17:17:59 Pablo Sanchez wrote:

Morning!

>Oh, sorry for being unclear.  What I was trying to say is given the
>set of changes from one version to others, it's usually most fruitful
>to look at the current s/w and fix it.

Sure. 
>I'm not denying the above.  I suspect your impressions are right.
>Ultimately the goal is to fix the existing s/w so that's why I tend to
>focus on it (when I'm in charge of fixing P&T issues.  :)

I agree. However, in this particular case those "forward fixes" are going to take a certain time to arrive. You've already seen Daniel write about doing certain things "in frameworks"; that means it's more than likely that any real fixes are going to be for the KF5 (KDE4's successor) version of KMail & friends. I understand that, I even agree, but I don't like it. I find KF5 to be far from "production ready" from playing with it through KUbuntu's Project Neon5 (and I'm developing a distaste of Qt5), and I do happen to use KMail. Having to coerce it and its akonadi minions to do what I want basically every time I want to do a quick check of my email is not something I'm going to put up with any longer.

For the record: since downgrading I have not yet had to restart any of akonadi or kontact. I've been able to suspend the netbook by closing the lid without thinking, and this morning everything seems to have woken up fine without taking "forever" to sync.

>The data doesn't indicate the above at all.  What I saw is we're
>hitting the database very hard.  Doing some crude sampling against the
>database I showed the queries.  These queries, as I mentioned, are
>nearly unbounded:  no timestamp is used to reduce their database
>bandwidth demand.

I was hinting at the description Daniel gave about what I'll summarise as the redundant back and forth conversion of data. You're right of course, that doesn't mean the database is not also a bottleneck, or the actual bottleneck. (I have no idea what the term "ASAP" means in this context.)

>> on one of the Arch wikipages to unset an innodb setting related to
>> aio_write on ZFS. Not that I ever saw the error in question, but I
>> guess I should figure out what that setting does (I just suspended
>> my Linux rig so I don't have the exact name handy right now).
>
>The database is not I/O bound.  It's CPU bound so unfortunately no
>amount of I/O tuning is going to help.

The setting in question is "innodb_use_native_aio=0", the WIKIs 
https://wiki.archlinux.org/index.php/MySQL#OS_error_22_when_running_on_ZFS and 
https://wiki.archlinux.org/index.php/KDE#Akonadi

(which in fact I found trying to figure out how to get rid of the Baloo error that the Xapian db cannot be found (i.e. how to create it). No luck on that one yet, got more interesting stuff to do anyway :))

René
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users