Over time a lot projects start consuming rather more than less memory. Mostly it’s not due to the added features themselves. Often it’s rather due to the amount of code growing and maintainability getting harder. A result is often that the good ideas and great ideals about memory consumption fade away a little bit.
I disliked that strategy from day one for the tinymail project.
Also note that most of the times just throwing more into ram, does not necessarily mean that your application will perform better. Often the exact opposite is the case: because it’s often due to your design being broken. Most hacks are just what they are: hacks. Most hacks are in reality slowing down things too.
I made the decision that I will design in a flexible and adaptive way starting day one. This means that new features have always been easy to add to the framework, cause of its design. It’s a misconception that good design automatically means a lot memory consumption. In fact, the contrary is often true. It’s also a misconception that you can’t use C for this. When designing, the programming language is mostly irrelevant. Although D is indeed a kick ass programming language :-) (boy, it feels good to say subjective crap in my blogs. Moeha!).
I remember the days when I flooded my own blog about how tinymail was only consuming something like say ~18MB of heap allocations for displaying a folder of 50,000 items. Well, I have improved that figure a little bit. Today tinymail consumes 8,613K when displaying a folder of 50,000 items, with a ~10MB mmap (which hasn’t significantly changed since).
I made a new memory report which is available on the trac. I added quite a lot documentation about mmap, about how tinymail uses the memory and about the slab allocator. I did this to make sure that people who’ll be really reading the report will have as few misconceptions as possible.
You can of course reproduce the report and all steps for reproducing it are documented too.