Re: [Evolution-hackers] Memory consumption and virtual machines

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote:
> I have to wonder if it's even worth ever merging the mmap hack into
> Evolution at all. If the plan is to finish Zucchi's disk-summary branch,
> which also solves the memory problems (afaik) as well as:

> 1. introducing an API for using cursors to get at message infos
> 2. better designed on-disk format that uses B-Trees

When? I'm also very interested in this for tinymail.

> the problem with philip's mmap file format is that the strings that will
> be hit for sorting/viewing/etc are all spread out over a huge number of
> pages.

My own tests indicated that it's as-fast as the old implementation. Some
test (like sorting) where even faster. I'm guessing mostly because qsort
doesn't make large jumps afaik.

I mostly fear NFS shared $HOME folders.

> I just see this being re-examined later to try and design the
> format to better optimise it by compacting all the strings into a strtab
> type thing.

That would be an excellent idea.

> I also don't like how it has to reload the summary anytime new messages
> arrive.

This is exactly the same as the current implementation. The current
implementation does exactly the same and isn't changed at all.

Look at the patch. It doesn't change anything to reloading the summary.


> I just don't get the feeling this is really all that well thought out
> and it scares me.

So lets test it then?!

> I'd just hate to see a rush job come out of this
> 
> Jeff
> 
> 
> On Tue, 2006-07-18 at 13:26 -0500, Federico Mena Quintero wrote:
> > On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote:
> > 
> > > I'm waiting for the decision (yours) of making this optional using a
> > > compilation flag or at run-time.
> > 
> > Let's do this in the usual manner:
> > 
> > 0. Polish the patch in the usual way:  make sure it follows the
> > indentation and naming conventions of the surrounding code, etc.
> > 
> > 1. Branch evolution-data-server into HEAD (development, with Philip's
> > patch), and the stable branch (without the patch).
> > 
> > 2. Make the patch *mandatory* in HEAD, so that it gets a good amount of
> > testing.
> > 
> > 3. ???
> > 
> > 4. Profit!!!
> > 
> > I'd suggest that (3) become "write a good stress-test suite for Camel,
> > independent of Evolution".  We need that anyway.
> > 
> > Novell already has a bunch of LDTP stuff to test the Evo mailer from the
> > user's viewpooint - run those tests on the patched version to see how
> > well they work.  [Varadhan, those tests are already part of our QA
> > process, aren't they?]
> > 
> >   Federico
> > 
> > _______________________________________________
> > Evolution-hackers mailing list
> > Evolution-hackers gnome org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
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