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
_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
