76118 - marking msg read or unread or flag/unflagged consumes 20K of memory

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[David :Bienvenu]

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.

Comment 1

[David :Bienvenu]

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!).

Comment 2

[David :Bienvenu]

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.

Comment 3

[scottputterman]

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?

Comment 4

[David :Bienvenu]

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.

Comment 5

[David :Bienvenu]

Attachment: proposed fix

Comment 6

[David :Bienvenu]

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.

Comment 7

[David :Bienvenu]

Attachment: fix to completely remove offending code

Comment 8

[Navin Gupta]

if it works, r=naving

Comment 9

[(not reading, please use [e-mail] instead)]

sr=sspitzer

if this will introduce any leaks, can you log (or re-open) bugs on those leaks? 

Comment 10

[David :Bienvenu]

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.

Comment 11

[David :Bienvenu]

fix checked in.

Comment 12

[esther]

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.