I created a new patch that fixes a few things (about the previous patch). The mailinglists are slow (the hackers and patches mailinglists of evolution are in CC) so I can’t yet point to the changelog E-mails. But I guess you can soon follow it up there.
Of course, what you guys care about is fancy graphs. The first shows tinymail opening and closing the ~650 headers folder a few times (this time without the leak). And the second is tinymail opening and closing the ~14550 headers folder.
While finding my leak I also learned that the original implementation of camel-folder-summary.c did an unnecessary strdup() and did some funny unneeded memory segmentation. I created this patch that fixes the unnecessary strdup. The memory segmentation fix is already committed upstream (and is for-free fixed by the mmap patch of course).
The strdup caused ~300kb unnecessary memory for the 14558 headers folder, and ~40kb for the 658 headers folder. In my opinion that’s a lot for memory that isn’t needed at all.
Everybody: please start using valgrinds massive tool aggressively on every change you make to your code. The difference between token = strdup(tokens[i]) and token = tokens[i] can be a lot memory! You can make little children, that will use such a OLPC device, happy with it.
If you want to make a real difference in Evolutions memory usage, check the imap_rescan method in camel-imap-folder.c. There’s huge room for improvement in memory usage in that method (or something that is related to “scanning messages”). Valgrind shows me up to 50MB of memory usage just for scanning for the new messages of ‘one’ folder (the ~14550 headers one).
Don’t think Evolution doesn’t need our community help. Let us fight this memory monster together shall we? Hows that for a positive message, jdub? ;-). There’s definitely very interesting components (like Camel) that aren’t very monolithic. You *can* make a difference, just checkout the code and start hacking on it.