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 > about > mailinglists and all this automated server notifications this could save > quite > 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 > which > 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 way. 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 Evolutionfirstname.lastname@example.org http://mail.gnome.org/mailman/listinfo/evolution-hackers