KMail stats

[George Staikos]

Here are some average statistics:

minutes:seconds, peak cpu used (dual cpu Athlon, full = 200%)
Mail server was kolab connected via 10Mbit lan with two switches and a 
firewall between.  Mail spool size: 244196KB

Build Cache
--------------
KMail - last week				Normally goes OOM and crashes, full CPU
KMail - w/memleak fixes		11:25, 78% (X11 was at 50-70%)
KMail - w/memleak+optimize	11:03, 65% (but X11 was at 50-70% too)
Mozilla 1.4					29:00, 15%

Synchronize
--------------
KMail - last week				00:24, 165%
KMail - w/memleak fixes		00:27, 165%
KMail - w/memleak+optimize	00:18, 150%
Mozilla 1.4					00:13, 7%


Cpu usage: This is a very major factor for KMail.  Both KMail and kio_imap use 
far too much CPU.  KMail could even gain 3-5% just by redoing the progress 
stuff.  Calltree shows a very large number of signals emitted, and a huge 
amount of time spent drawing progress bars and the folder tree.  kio_imap 
does far too many mallocs (12 million per synchronize alone!), and too many 
data copies.  All CPU times for kmail were combined with the imap slave, and 
in all cases, they were taken while processing a big folder (at their peak).

Mozilla updates its UI very sparingly - not surprising given how slow it tends 
to be.  The KMail progress dialog HAS to go, and we would do well to rework 
the foldertree.  This is a very major thing I think.  We should also only 
trigger foldertree updates at most every 500ms or so (maybe more) when bulk 
operations are happening.  => Compress the events, send in bulk.  We clearly 
repaint the tree even if the folder that's being updated is collapsed.

I think kmail is within about 50% of the maximum time that cache building can 
be done, which is good.  We just need to bring down CPU usage in the slave 
and the app so that the computer is usable while a mail check is running.

The optimization work I did on kio_imap is quite apparent in synchronization, 
but not so much in cache building.  This was not unexpected.  I only tried to 
optimize synchronization since I don't often rebuild the cache.

The KMail build was not changed in those number above, only kio_imap.  KMail 
is HEAD as of right now.  Also note that these numbers become much more 
important on slower and UP systems.  The speed improvement is very 
noticeable.

Why did I not show results from Evolution?  Well let's see.... I installed 
Evolution 1.2.2, it ate one mailbox (luckily it was only konq-bugs), I 
couldn't for the life of me figure out how to tell it to sync all my 
mailboxes (I selected them all, but it only downloaded about 3MB for "offline 
mode"), and there was no way I could discern to time how long it took for a 
mail check cleanly as I couldn't tell what it was checking and when it was 
checking it.  I gave up on that pretty quickly.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/