The following valgrind massif report was created using a standard tinymail from Subversion and a Camel build using camel-lite-builder from Subversion.
It’s using gslice (small leaks aren’t visible). It’s being ran on a x86 i386 architecture . This makes a significant difference if your pointer size isn’t four bytes: the type representing a summary-item — of which the visible subject, to and from headers are components — consumes a bunch of pointers per instance.
It’s using Gecko for displaying HTML E-mails which was first used around point C in the graph.
A detailed memory-analysis of tinymail can be found (and improved by you, as it’s a wiki) here. Note that the memory-analysis that you can find there, isn’t using gslice (and if you improve it, don’t use gslice for your tests).
Note that I indeed cropped the image a little bit. The removed pieces of the image aren’t (yet) very interesting.
Let’s iterate over the marked points:
- A is the start of the application. At this point aren’t the folders loaded, but the accounts are;
- B is when the folders are loaded and the demo-ui of tinymail is fully visible and usable for the user. Everything that doesn’t fully go back to this position can be considered being a leak. But be careful when thinking about leaks: during the graph several things are kept in memory. The worst memory consumer being kept in memory is Gecko which gets allocated at point C. Others are the folders, the accounts and Gtk+ components and caches.
- Between B and the start of C is the point where I opened my INBOX folder of ~ 1,000 messages.
- C is when I first clicked an E-mail that contains a “text/html” mime-part. As a result of that, a GtkMozEmbed widget (this is a Gtk+ wrapper for Gecko) is instantiated. The memory between C and D minus E is what Gecko consumes;
- What I did at D was that I clicked another folder. The HTML message and folder of B and C where unloaded. But because Gecko upon destruction keeps itself cached, you don’t see a major memory reduction here;
- The interesting part starts at E where I clicked a folder that contains no messages (My Drafts folder);
- F is when I reopened the first folder. You see all the memory go up and down completely. This is important of course (else I’m leaking things);
- At G/a I clicked on a NNTP folder. The folder was “C++” of the newsserver at digitalmars. What you are seeing between G/a and G/b is what I think is the Camel NNTP library being loaded and consuming some of the memory. But I can be wrong as I haven’t in-depth investigated this;
- H was when the folder was fully loaded;
- I was when I clicked on that Draft folder in my IMAP account;
- J was opening the “C++” folder of the digitalmars newsserver again;
- K is the Draft folder;
Tinymail is (slowly) getting more and more contributors and is increasingly becoming serious. I can’t open all details, but Nokia is indeed interested in tinymail. I decided to become semi self-employed for smaller projects and my full-time employer agreed to sell my consultancy for larger tinymail projects. Other companies that will help you with tinymail consultancy are Kernelconcepts and Collabora. If you or your company is interested to get on the support pages of tinymail, contact me. About politics: my philosophy about software doesn’t allow me to obey any employer in case he wouldn’t allow me to add your company on that page.
The license of tinymail will forever stay LGPL. Like its license will the spirit behind the project also always be a free software one. But I (its maintainer) isn’t dirty of selling consultancy around it. It’s okay when others do this too. I, however, encourage organizations (philosiphical and technical) to contribute their platform–specific code back into the LGPL project. If necessary (and only if necessary) I will dual license certain things for this. My opinion is that availability of the code and work is more important than religion.
Major (indeed major) memory reduction is still possible (mostly within Camel) and is being worked on. Support for non-Gtk+ platforms is on the agenda (and certainly isn’t impossible). Examples are WinCE and Qtopia. Support for those will, however, not be available at a first release. It’s simply too much work and it would delay such a first release significantly. It’s not that I’m politically not interested. I am technically interested and will put my own time in it if necessary. Also note that I don’t care about anti-Microsoft idiots who will condemn me when I’ll support WinCE (and I will). I propose them to write their own tinymail if that disturbs them.
That’s it for todays tinymail blog.