Re: [Evolution-hackers] Moving the struct instance heap space to mmap

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:

> typedef struct {
> CamelFolderSummary *fs;
> int nth;
> MemoryMessageInfo *m;
> } CamelMessageInfo;
> 
> 
> #define camel_message_info_from (x)                               \
>     ((x)->m ? (x)->m->from : (x)->fs->sstart+*((x)->fs->istart    \
>      +(sizeof(int)*4*(x)->nth)+1))
> #define camel_message_info_subject (x)                            \
>     ((x)->m ? (x)->m->subject : (x)->fs->sstart+*((x)->fs->istart \
>      +(sizeof(int)*4*(x)->nth)+2))
> #define camel_message_info_from (x)                               \
>     ((x)->m ? (x)->m->to : (x)->fs->sstart+*((x)->fs->istart      \
>      +(sizeof(int)*4*(x)->nth)+3))

Note of course that once the offsets are stored in the mmaped index
file, you can have a lot more than just the from, subject and from
members at almost no cost (only mmap & file size). Whereas today the
entire structure size for a camel-message-info grows to more than these
120 bytes.

That is the core idea here: reduce the size of the camel-message-info
type so that each instance needed is relatively small. Each instance
will do a two-stage lookup in two mmapped files. Once for knowing the
offset and once for getting a pointer (at that offset) with the actual
data. Each instance that isn't yet written to disk, has a normal memory
copy using the "MemoryMessageInfo" struct.

In stead of 120 bytes would this camel-message-info consume (aligned on
four bytes, as on a x86 i386) 12 bytes. That's 10 times less per item.

ps. I'm indeed interested in your input/ideas on 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