[Kde-pim] Akademy results: kmail-2 issues

[Thomas McGuire]

Hi,

replying only to some points I know about.

On Sunday 11 July 2010 12:49:36 David Faure wrote:
> 3.2) Upon restarting kmail right afterwards, it crashed again with
>    ASSERT: "source_index.isValid()" in file
> /d/kde/src/4/kdelibs/kdeui/itemviews/krecursivefilterproxymodel.cpp, line
> 286 (KRecursiveFilterProxyModel::filterAcceptsRow)
>    gdb says: sourceRow = 1, sourceParent is invalid index, sourceModel() is
> a Akonadi::CollectionFilterProxyModel. kdelibs is from 4.5 branch, just
> like everything else in this report.
>
> [..] 
> 
>    Help! I cannot start kmail anymore.
>    How do I debug this?

Workaround: Delete everything in $KDEHOME/share/apps/kmail2/autosave/
As of how to debug that, it is still on my list Akademy backlog todo list to 
do that myself, using the model logger in kdelibs that Steve wrote.
Who knows, maybe Steve will even be faster than me with this ;)

> 3.3) The performance of the message list is a huge problem. This is
> probably -the- reason I will not be able to use this version of kmail for
> now, despite all the crash bugs. Switching folders is just far too slow. I
> don't have more data on this one, but I heard others have profiled it etc.

The performance is indeed a very big problem, and will likely also be a 
blocker for myself.
See also https://bugs.kde.org/show_bug.cgi?id=244503.
Part of the overhead is caused by parsing each header in the list on the 
client side, which wasn't done in KMail 1. For that, I created a kcachegrind 
profile, see www.kdab.com/~thomas/callgrind.out.32281. Of course kcachegrind 
could only detect CPU usage in KMail itself, very likely there is some 
overhead as well when waiting for the Akonadi server to perform the request, 
and then to read the request from the socket.
For the parsing problem, the solution would be to not store the KMime header 
on the Akonadi server, but rather store a format that is suitable for fast 
progressing on the client side, similar to the format in KMail 1's index file. 
That would also make the IO bandwidth lower.

The other thing which Milian mentioned is that earlier versions of KMail also 
used a threading cache, which made message list population faster. That 
however was already gone with KDE SC 4.2, IIRC.

>  Even the performance of the messageviewer seems poor. When my kmail starts
> again I will debug why there seems to be a kio job doing a get() on $PWD,
> but other than that, I wonder what makes it so much slower than in kmail1.
> More precisely, this is while rendering the "about" page, not the email
> itself, but this happens every single time the user switches to another
> email...

My guess is that fetching the message from Akonadi simply takes longer. The 
splash screen thing also seems to have problems, sometimes it says "Retrieving 
folder contents" and sometimes it says something like "Loading message", which 
is strange. The splash screen should also be changed to be only shown after a 
certain timeout, if that doesn't happen already.

> Oh and: I completely lost this email, since kmail crashed just after
> removing the autosave file :

Strange, I wonder how that can happen. KMail only removes the autosave file 
when closing the composer window or when having sent the mail, so simple 
crashes should not do that...

> 3.6) The order of resources is undefined, and the order of folders is
> almost-alphabetical but when clicking on special folders like 'outbox'
> they "jump" to the top of the list.

The jumping of folders is a known bug, I think Steve might know more about it.

> 6.2) it seems that when selecting 100 messages in kmail's messagelist, a
> Monitor with "fullPayload" is watching these 100 messages. Which means
> it's fetching them fully when moving them elsewhere, which makes things
> slow. I see "full payload" jobs happening on all items, slowly.
> Proof:
> kmail2(6822)/libakonadi Akonadi::Monitor::setItemMonitored:
> Akonadi::Monitor(0x23f3e20) item= 305814 monitored= true now monitoring 43
> items (see http://www.davidfaure.fr/2010/monitor.cpp.debug.diff for the
> debugging patch)
> 
> The origin of this monitor is:
> Akonadi::Monitor::Monitor: Akonadi::Monitor(0x23f3e20) created with parent
> KMail::MessageActions(0x23e5cc0)
> 
> The code says:
>   mMonitor = new Akonadi::Monitor( this );
>   //FIXME: Attachment fetching is not needed here, but on-demand loading is
> not supported ATM mMonitor->itemFetchScope().fetchFullPayload();
>   connect( mMonitor, SIGNAL(itemChanged( Akonadi::Item, QSet<QByteArray>
> )), SLOT(slotItemModified( Akonadi::Item, QSet<QByteArray> )));
> 
> This seems to be for some mailing-list detection feature? On 100 selected
> items? I don't get it.

The code is not really related to mailing lists, but still a WTF indeed. When 
an item changes, it calls updateActions() to change message-related actions, 
for example those in the context menu. Definitely not something the full 
payload is needed for, and I also wonder why the items are remebered in 
mVisibleItems...

> Who said you had to release a beta in order to get feedback? :-)
> 
> This code is definitely not beta-quality yet,

I, of course, agree with this.

Regards,
Thomas
-------------- 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/20100713/4485c1a5/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/