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

[Parthasarathi Susarla <sparthasarathi novell com>]

Hi all,
I second fejjs thoughts.
Also i have been testing the patch for sometime now. Heres the
inference:
* The patch works in reducing the memory consumed during the initial
startup of evolution. And it does a wonderful job of that.

* The patch intends to fix the overall consumption of memory during the
usage of evolution, and it does *not* do that. I kept evo running with
this patch in for more than 8 hours and using Evo as i would use it
regularly. (Reading of new mails, changing folders....blah! blah!) and
more than a couple of hundred new mails later and modifying the summary
file as many times we lose the memory gain we got initially. 
I *dont* have fancy graphs to display this information though - but i
surely have the data and the necessary information i need.

* mmap is *not* the solution to this problem - it helps to a certain
extent. 

* Generating message list each we get a new message is bad enough - we
dont want to reload the summary file each time. 


I still have not tested philips latest patches. I gather he has
improvised on the older patches. Would report on the patches after i
test them enough.

Cheers,
partha


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
> 
> 
> 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. 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.
> 
> I also don't like how it has to reload the summary anytime new messages
> arrive.
> 
> I just don't get the feeling this is really all that well thought out
> and it scares me.
> 
> 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
-- 
Parthasarathi Susarla <sparthasarathi novell com>
Novell Software Development (I) Ltd.