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