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 <[EMAIL PROTECTED]> Novell Software Development (I) Ltd. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list