Re: mmap() for the summary file

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