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

[Federico Mena Quintero <federico ximian com>]

On Fri, 2006-09-08 at 10:37 +0200, Philip Van Hoof wrote:

> Yes. This sounds possible. Each member of the summary, however, would
> need a length (or a lot strlens are needed per access).

Oh, so those lengths are not stored.  Bummer.

Some ideas:

1. What is the maximum length of those strings?  What is the maximum
length of one message header in the summary file?  In the message info
struct, can you use short ints for offsets instead of full pointers?  Or
even single bytes for lengths, if the strings are really short?

2. What are the access patterns?  When the array of summaries gets
accesed, do you need all the fields, or only some of them?  I.e. you may
need to access some flags directly, but you may be able to afford
computing some lenghts by hand if you are doing an uncommon operation.

3. Even if some things get accessed frequently, some others may not be.
All my message folders show the default columns:  Flags, From, Subject,
Date --- these are all fields in CamelMessageInfoBase.  However, some
others don't get displayed at all:  mlist, to, cc, etc.  Can we remove
those pointers from the struct, and compute them on demand?  [Those
fields may be used when filtering, especially mlist.  But filtering is
pretty much only done when you fetch new mail (isn't it?), so you can
maybe compute that field on demand instead of keeping it around.]

The goal is to reduce the working set.  Moving all that stuff to another
mmap() cache just moves your working set from the heap to elsewhere :)

  Federico