Everytime I mark a local message read or unread, or flagged/unflagged, it consumes 20K of memory per message. Not sure if it's because of the outliner drawing or clearing the icon, or if something in the mail/news backend (e.g., updating the mozilla status flag) is consuming the memory. Need to investigate.
this is true of local msgs and not of imap msgs, so it's not an outliner problem. It may have to do with committing the mork database (god, I hope that's not the problem!).
it does seem that commiting the db's consumes the memory; if I comment that out, the memory isn't consumed. It may not be a leak per se, but rather, bloat. Still, mork commits should not consume memory so nominating for beta.
I'm marking nsbeta1+ because I'm assuming it means when reading messages to. It seems like this could lead to large bloat pretty quickly. What about news?
local mail is the worst because each flag toggle does a session commit, which seems to consume a fixed 20K. The other protocols (news and imap) don't do commits as often, and when they do, they do large commits, which don't consume as much memory. I've got a change in my tree to not do session commmits for local mail, which will ameliorate some of the damage. But this does need to be looked into.
Mork has a feature where you can associate an allocator with an env, and I used this feature with the environment created by the panacea.dat mork db - the allocator I used was a pool allocator which I freed up all at once at the end. BUT, it turns out that mork was using the pooling allocator for db's other than the folder cache (grrr...) so I'm going to stop using the pooling allocator completely. It was probably a bad idea in the first place, but it did prevent memory leaks. (I used it for the folder cache because we keep that open the whole time mail news is up, so we might as well free it up all at once.) The patch just stops creating and using the pool. I'll clean it up some more after I do some testing.
if it works, r=naving
sr=sspitzer if this will introduce any leaks, can you log (or re-open) bugs on those leaks?
it might cause leaks to suddenly appear, but it won't create any new real leaks because we were using an arena before, which gets freed up in one fell swoop when we shut down.
fix checked in.
Using build 2001-05-14 on win I compared the memory usage between this build and a build where the problem was reported. On the 4-10 build, there was a constant memory usage change when marking msgs as read or unread in the local folder. I then watched the memory usage for the same scenario with today's build on windows. The memory usage did not change every time I changed the unread/read status of messages. If I need to test this another way please reopen and give steps. Verified.