Comments on: camel-folder-summary.c http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc From the mind of Philip Sun, 28 Aug 2011 12:59:07 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: pvanhoof http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-168 pvanhoof Thu, 22 Jun 2006 15:27:15 +0000 http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-168 Also note that the current implementation also keeps the entire current summary info in memory (at all times). So the same amount of memory per folder would be used. Except that now it would be in the format of an mmap() rather than a series of malloc()'s filled in with the results of an fread(). Also note that the current implementation also keeps the entire current summary info in memory (at all times). So the same amount of memory per folder would be used. Except that now it would be in the format of an mmap() rather than a series of malloc()’s filled in with the results of an fread().

]]> By: pvanhoof http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-167 pvanhoof Thu, 22 Jun 2006 15:22:21 +0000 http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-167 Hey hoa, note that camel wouldn't need to keep entire mbox files open. Camel keeps just the summary info in a file. Such a file is ~ 200kb in size for a 1,000 headers folder. It would be possible (for tinymail) to close the mmap each time the folder is not active anymore. It wouldn't be possible to set this behaviour in Evolution. The vfolders feature of evolution requires the folders (an summary mmap()'s) to remain open. Hey hoa, note that camel wouldn’t need to keep entire mbox files open. Camel keeps just the summary info in a file. Such a file is ~ 200kb in size for a 1,000 headers folder.

It would be possible (for tinymail) to close the mmap each time the folder is not active anymore. It wouldn’t be possible to set this behaviour in Evolution. The vfolders feature of evolution requires the folders (an summary mmap()’s) to remain open.

]]> By: hoa http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-166 hoa Thu, 22 Jun 2006 15:03:26 +0000 http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-166 In fact, in libetpan, using mmap for mbox and maintaining all mailboxes opened revealed to be a problem. The process had a huge virtual memory (and resident memory). This made other applications swap a lot. I guess that we can improve the behavior by unmapping files when they are not needed for a while but I don't know what is the behavior of the kernel. Does it keep most frequently blocks of the file in memory or are they flushed and reloaded ? Case where the performance would be bad. In fact, in libetpan, using mmap for mbox and maintaining all mailboxes opened revealed to be a problem. The process had a huge virtual memory (and resident memory). This made other applications swap a lot.
I guess that we can improve the behavior by unmapping files when they are not needed for a while but I don’t know what is the behavior of the kernel. Does it keep most frequently blocks of the file in memory or are they flushed and reloaded ? Case where the performance would be bad.

]]> By: murrayc http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-165 murrayc Mon, 12 Jun 2006 06:19:57 +0000 http://pvanhoof.be/blog/index.php/2006/06/11/camel-folder-summaryc#comment-165 > The reason why I think it would dramatically improve the situation is that with mmap(), the kernel gets to decide about whether or not putting the memory in its buffers/cache I thought that chunks of mmap()ed memory were just loaded into memory when used. Are the chunks also put back onto disk or virtual memory when not used for a while? If not, it seems like it might force evo to hold on to a lot of non-cacheable RAM. Reducing frequent memory copying does seem like a nice performance aim. > The reason why I think it would dramatically improve the situation is that with mmap(), the kernel gets to decide about whether or not putting the memory in its buffers/cache

I thought that chunks of mmap()ed memory were just loaded into memory when used. Are the chunks also put back onto disk or virtual memory when not used for a while? If not, it seems like it might force evo to hold on to a lot of non-cacheable RAM.

Reducing frequent memory copying does seem like a nice performance aim.

]]>