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

List:       kmail-devel
Subject:    Re: KMMsgDict slowness
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <ingo.kloecker () epost ! de>
Date:       2002-01-02 23:02:56
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 03 January 2002 06:09, Ronen Tzur wrote:
> 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.

Is it? If we always choose a prime number p with p ~ 5/4 n where n is 
the number of messages then we use about 25% more memory than 
necessary. Does adding four bytes per message also only increase the 
memory by 25%?

Regards,
Ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8M5GlGnR+RTDgudgRAlmkAJ0Xga/8HMLPkF3totjk5Zz8kD1iAgCfcuiB
ej+0hAQFQBvQptbEW3RdFTI=
=Akk4
-----END PGP SIGNATURE-----
_______________________________________________
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]