On Mon, 2006-06-19 at 11:56 +0200, Florian Boor wrote:
as long as we talk about individual senders this is true, but if you think
mailinglists and all this automated server notifications this could save
some memory. As long as it is possible to implement this without a too big
effort and code overhead it would be useful. Of course - even saving 100kb
would be optimistic for a huge mailbox is not be worth to mention on a modern
PC - but on a mobile device that would be nice to have.
But the complexity for getting this *in* the file that is to be mmap'ed
does increase then. Also the backward compatibility is undoable this
You'll need to implement some sort of hash-table with pointers to
strings at the beginning of the file, hash-keys in the summary tree
itself. And the strings at the end of the file.
Agreed that this would dramatically increase loading time (the time
needed to seek/walk-a-pointer over the entire mmap()ed file and create
summary-info structs). As it would decrease the amount of data that is
to be mmap()ed.
I agree this is worthwhile for the current read() to memory
implementation. I don't think the complexity is going to payoff in real
improvements for a mmap() implementation of it. But I would,
nevertheless, be very interested in the experiment.
Note that there's an mmap() on Windows and that glib abstracts it with
some glib API. I would of course use the glib abstraction API for this.
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Evolution-hackers mailing list