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

List:       kmail-devel
Subject:    Re: KMMsgDict slowness
From:       Ronen Tzur <rtzur () shani ! net>
Date:       2002-01-03 13:38:57
[Download RAW message or body]

On Thursday 03 January 2002 04:14, Michael Häckel wrote:
> On Thursday 03 January 2002 06:09, Ronen Tzur wrote:
> > It's not about the amount of work.  I think it's not right to divide this
> > into two different steps, the first actually moving messages, and the
> > second updating the dictionary.  Even more so when the overall design in
> > KMFolder-related classes is to handle one message at a time.
>
> Why not?

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.

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.

>
> > My feeling is that if by optimizating the dictionary, the current design
> > is still acceptible without having to apply further patches on it, then
> > so be it.  And if and when this part of KMail gets redesigned, that would
> > be the time to deal with issues like this.
>
> I simply don't believe that. Even if KMail then would manage to remove 20
> messages per socond from a folder with 15000 messages that are still only 5
> messages per second, if the folder contains 60000 messages, as long the
> code is O(n^2).

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.

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.

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?

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.)
_______________________________________________
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]