On Fri, 2006-11-10 at 10:23 +0100, Philip Van Hoof wrote: > On Thu, 2006-11-09 at 22:57 +0100, Philip Van Hoof wrote: > > I'm committing this. If it really doesn't work, I'll roll it back. But > > my first tests tell me it's working as expected. > > Note that this commit introduced a big memory leak in the content-info > when downloading new messages from for example an IMAP service. > > Fixing this I conquered all the leaking. I'm still seeing one leak: the first time I remove a first header (the first time expunge happens). It's the fourth peak in the massif report. This is obviously a full folder not being freed. Which probably has a good reason, so I'm trying to find that reason. You also see a veeeerrryy tiny leak if you check peaks 4 until 8. I haven't found that small little bitch yet. I think it's going to be one heap allocation of a few bytes or something like that :-\ What you see in the massif report is how I first opened folder 2000 on the test account, closed it (three times), then I removed a header and closed the folder, reopened it, removed another header, closed, reopened, etcetera. In the last two peaks I didn't remove any header. Not sure if that's visible (I wanted to see whether there's going to be a difference after some removing has happened). > > On Thu, 2006-11-09 at 17:13 +0100, Philip Van Hoof wrote: > > > Use this one (enables the expunging when removing items) > > > > > > On Thu, 2006-11-09 at 16:24 +0100, Philip Van Hoof wrote: > > > > On Thu, 2006-11-09 at 15:42 +0100, Philip Van Hoof wrote: > > > > > This one seems to work. > > > > > > > > > > Can people please test this (a LOT)? > > > > > > > > I'm still too unsure about the patch to already commit it (this doesn't > > > > happen a lot) :-) > > > > > > > > It needs testing, again testing and more testing. Once it works, it will > > > > solve a lot limitations and problems that the mmap technique introduced > > > > (mostly the fact that any change to a single such header means having to > > > > reload all other headers. Which is a consequence of the fact that an > > > > mmap always means mapping the entire file -- in our case it means this, > > > > you can indeed map only parts of the file. But it's not practical to map > > > > regions as large as one header instance --). > > > > > > > > I'm still thinking about removing the messages_uid hashtable. Right now > > > > I have to duplicate the key (this is the uid) because remapping means > > > > also remapping the memory where the uid points to. That same memory is > > > > used as key in the hashtable. So also the hashtable (its keys) become > > > > invalid after unmapping and remapping the file. > > > > > > > > I solved this by duplicating the uid ans feed the hashtable that > > > > duplicate as key. This is why I said that this is going to consume a > > > > little bit more memory (a few bytes per header, added with heap-admin > > > > cost, multiplied by the amount of headers being used). > > > > > > > > The hashtable is actually only really needed for the > > > > camel_folder_summary_uid function. It can be implemented without this > > > > hashtable too, of course (a little search in s->messages). > > > > > > > > Thinking, abusing my brains, etc etc :). I can use opinions of the > > > > clever guys who sit here and read ;)... on this one. > > > > > > > > > > > > > > > _______________________________________________ > > > tinymail-devel-list mailing list > > > tinymail-devel-list gnome org > > > http://mail.gnome.org/mailman/listinfo/tinymail-devel-list -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be blog: http://pvanhoof.be/blog
Attachment:
massif.tar.gz
Description: application/compressed-tar