[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: KMMsgDict slowness
From:       Michael =?iso-8859-1?q?H=E4ckel?= <haeckel () kde ! org>
Date:       2002-01-03 14:30:05
[Download RAW message or body]

On Thursday 03 January 2002 21:39, Ronen Tzur wrote:
>
> Because it's not right (in my opinion) to separate serial number from
> message. If not physically by design in the program, at least conceptually
> they should be considered a part of the message.

It's not about philosophy here, but about programming :-)

> And practically, if it crashes during step 1 and before step 2, then you're
> in for some trouble as folders and dictionary get out of sync.  That may
> not be all that important today, but someday it might.

In the case of a crash, neither the index nor the serial number file is 
written to disc, therefore it doesn't matter, what happens in memory.
This results the mails remaining in the original folder and duplicates of them 
in the new folder. The duplicates get new serial numbers on the next startup 
because they don't have serial numbers at all. At least this is the way I 
think, it shold work. Ingo reported something different recently.

> But X messages per second also counts for the physical move of X messages
> between folders, ie disk I/O.  I think as the dictionary becomes faster,
> the part of disk I/O becomes more and more dominant factor in the X
> messages per second.

My hard disc seems to be able to copy about 45MB data per second. If I assume 
an average mail size of mailinglist mails with 4KB, that would be 1000 mails 
per second which is still far away from the speed we have now.

> So it seems to me that the claim that X messages for a folder with N
> messages is exactly (X/m) messages on a folder with Nm messages,
> is not exactly right.

For small folders it is not, but for big folders it is. For big enough numbers 
n every a*n^2 term becomes bigger than every b*n term, even if a is much 
smaller than b.

> Also, did you really think that first patch was going to make a difference
> between ten hours and fifteen minutes??  But you gave the idea of
> speedying up the dictionary a chance, and it proved itself, at least
> partially.   Why stop before we've exhausted all the options there?

Yet another 4 bytes per messages means for example for me yet another MB more 
RAM KMail requires and that only because there is some O(n^2) code that could 
also be changed to O(n) without a big problem.

> Then you'll be happy that it's fast, and I'll be happy that consistency
> is still maintained, and the world will rejoyce.   (Oh, and I'll even try
> to reduce the memory requirements, by not using QDict at all.)

If you introduce additional pointers to the items in the dictionary, isn't 
that just duplicate information and therefore just another possible error 
source?

Regards,
Michael Häckel
_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]