[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-02 22:08:55
[Download RAW message or body]

On Wednesday 02 January 2002 14:29, Michael Häckel wrote:
> On Thursday 03 January 2002 03:02, Ronen Tzur wrote:
> > I disagree.   When you changed the number of buckets to 199,999 you
> > made the lookup performed by dict->find(msn) faster, and just doing that
> > gave you a rate of 15 messages per second.   What I propose is to get rid
> > of the lookup entirely, so the result would be even better than 15.
> >
> > In my opinion, paying extra four bytes per message for this isn't that
> > costly. Would you reconsider?
>
> This is a lot of memory for people that have a lot of messages stored. This
> dictionary already needs quite some memory.
> I don't see a reason for wasting any amount of memory just because the
> algorithm used is stupid. And this algorithm anyway needs changing.

A few mails ago you were talking about selecting a prime number based
on the number of messages.  That translates to the number of hash
buckets, and is conceptually just as costly as adding four more bytes
per message.

Anyway, looking into Qt sources, it seems a bucket in a QDict actually keeps
the value of the key.   So with a bit of QDict subclassing, what I suggested
in the previous email might be possible without additional memory
requirements -- but at the price of some uglyness, and dependency on
the internals of QGDict.

> If you don't want to change that to update for all moved mails at once, I
> can also do that, I doubt, that this is much work.

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.

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