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

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2006-07-19 at 10:58 +0530, Parthasarathi Susarla wrote:
> Hi all,

> I second fejjs thoughts.

Note that fejj recently improved the patch by removing some ugly pieces
of it. Fejj and me discussed (thinks like) the patch on IRC.

Note that the patch also fixes a lot non-mmap related memory problems.

> 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. 

The memory that gets saved by the mmap technique is never reclaimed by
another (existing nor new) technique. Data that is made available using
mmap, is effectively never again made available using another technique.

This basically means that it's "technically" not possible that somehow
the patch stops saving the memory that it saves. What it saves from the
initial startup, it will always save.

It puzzles me a bit how you blame the increase of memory Evolution shows
you after eight hours, on the patch. How does it do that then?

Evolution consumes a lot real memory when it receives new messages. What
you are seeing after eight hours is the real memory being consumed for
this new information. The exact same real memory is also being consumed
without the patch, there's no difference here. There's no blame on the
patch for that. The patch still (for existing information) saves real
memory.

However. When you'll restart, that new information will be converted to
something that can be mmap()ed. Evolution will, after that restart, not
consume as much real memory for the same information (that is now on
disk and mmap()ed by Evolution).

Me, the current Camel maintainer Varadhan and old Camel warrior Fejj are
very aware of this. We have a few solutions in mind and will be working
on implementing these ideas. The solutions will not require a restart of
Evolution. The current patch requires this. 


This is not a technical impossibility. It's just something that isn't
technically implemented by the patch yet. Mostly because tinymail
doesn't need this restart (and the patch was initially engineered for
the purpose of tinymail).


> (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. 

There's solutions for this. 

> 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.


-- 
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