Another significant milestone has been reached for tinymail. I finally achieved getting the non-mmap memory consumption for the folder summaries lower than the amount of data being mapped using mmap.
These are averages but since all messages where spam, probably meaningful. You can read the source code of and compile and run this test to reproduce the tests yourself.
Loading 50,000 headers used to consume something like 30M. More typical numbers where the 10M for 15,000 headers. The idea was that not much people want to view 50,000 headers on a mobile device. Boy, I can come up with lame excuses for abusing your memory don’t you think?
Nevertheless, I improved the situation. 50,453 headers now consume 15.9M, 30,264 headers now consume 10M and 15,000 headers now consume 4.7M. At around 3,000 headers tinymail goes below the 1M barrier. Most people use their mobile device to view less than 5,000 headers. Making tinymail a cheap E-mail client infrastructure when it comes to memory consumption.
How did I do this? Well, I don’t yet support threaded sorting of messages. Therefore I removed that from the Camel that I’m using. This, for example, has cut 7% of the allocated memory usage. I also removed a few other pointers in the struct that is allocated per such summary item. Each pointer is of course 4 bytes on my test system. When dealing with 50,000 instances, it indeed becomes more significant.
Me and especially Matthew Barnes have also been upgrading some of the e-d-s infrastructure being used by Camel to modern glib functionality. Like GSlice in stead of EMemChunk (if done correctly, reduces heap admin a little bit it seems), GMutex in stead of EMutex, GThread/GAsyncQueue in EMsgPort and killing EThread. I also removed something called “tracing” and this debug-only “magic” checking from the CamelObject type (the magic stuff added 4 bytes to each CamelObject instance) and many other micro improvements. Most of the memory savings, however, happened by removing a few pointers from the CamelMessageInfoBase structure (the summary item structure in Camel). That structure is indeed a major contributor to why your Evolution is consuming a lot of your RAM.
Note that tinymail also uses an mmap. The size of this mmap is, at this moment, near the size of the allocated memory consumption. Does this mean that you need to double its memory usage in your mind? Not exactly. (On Linux) An mmap uses on-demand paging which is implemented in the kernel. Especially on devices with few remaining memory resources wont a tinymail based E-mail client consume a lot. The kernel will probably page-out most until you restart using the application.
I created a second memory analysis report for tinymail. You are hereby invited to reproduce the test and results. Feel free to add more memory reports and measurements yourself if you are interested in doing that.