I have made a new memory report on tinymail. Because tinymail and Evolution share a lot Camel code, I think the analysis is interesting for the Evolution team too.
http://tinymail.org/trac/tinymail/wiki/MemoryStats These are the structures of the CamelMessageInfoBase structure that tinymail's Camel removes. guint32 size; CamelSummaryReferences *references;/* from parent to root */ struct _CamelFlag *user_flags; struct _CamelTag *user_tags; Tinymail of course also uses the mmap patch. The references allocated accounted for 7% of all allocated memory usage. The three others are on a i386 x86 machine 4 bytes each. I don't use the size nor user_flags and user_tags properties of the summary items. So I've cut them out. Maybe a solution for Evolution would be load the references on demand to reduce the size? Since I'm not yet supporting threaded sorting in tinymail, and because I'm planning to implement support for this very differently, I decided to cut it out. I guess this is proof that Camel, with a few major adaptations, can be used for environments where memory consumption ought to be low. I'm planning to go even further and make more changes like these. I'm now trying to figure out a less memory consuming solution for the CamelMessageContentInfo structure (16% of all allocations are such instances). After that I will focus on the "getting new headers" problem of the mmap patch once more. I'm also playing with the idea of fully replacing the CamelFolderSummary implementation with something that uses a sqlite or db2. That one is a little bit a dilemma at this moment for me: it would probably start looking like the disk summary concept, etc etc etc ... ps. Feel free to ask me not to post reports like this on the evolution hackers mailing list if you really feel that this has nothing to do with evolution. Since both projects use Camel, I have a different opinion but I wouldn't contest yours. -- 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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
