Re: [evolution-patches] Fix for "agressive" memory segmentation

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-07-06 at 15:18 -0400, Jeffrey Stedfast wrote:
> For some strange reason I thought the pstring stuff already did that,
> oops. I guess I was thinking of similar code I wrote a few years back
> for another project...
> 
> This patch does it the way I had done it in another project of mine

Yours looks a little bit more clean in naming and stuff like that. It
probably does more or less the same? So I'd say commit one of the two?

Mine made some significant differences when running it with valgrind. It
was also a little bit faster in cachegrind (probably because there's
less malloc()'s and free()'s happening).

I'm still committed to the mmap() idea. Although I don't know for sure
keeping folder-count amount of file descriptors open is a very good
idea. I know the disk-summary branch would help a lot here. Regretfully
that one isn't yet finished ;-).

However. In tinymail I open and close folders much more quickly (each
time a folder becomes inactive, I close it). Therefore I'm almost
certain that for tinmails case the mmap() idea is going to significantly
improve the situation for larger folders. I might introduce a compil-
ation switch at the configure script.

I wonder, would such a patch (in case it's clean and doesn't harm
Evolution more than that Evolution would gain from it yadi yada) get
upstream? The patch would definitely bump the version number of the
summary file from 13 to 14. It would add a '\0' at the end of each
string in the file, and it will add one to the length-bytes in front of
the strings .. also in the file (which is forward compatible, so going
back to an older Evolution version will work with the same summary
files).


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