On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote:
Op 23-1-2012 15:54, Richard Heck schreef:
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of
valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
Like what Stephan reported, we see:
fantomas: ms_print massif.out.24204|grep TextClass::TextClass
->01.02% (303,120B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.16% (972,720B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.06% (1,262,880B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.56% (1,486,080B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.12% (1,642,320B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.06% (1,709,280B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.74% (1,865,520B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.54% (1,932,480B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
We see that the number of allocated TextClass objects increses. I
think that we never release buffers cloned by autosave.
I think I understand what's going on here. We release the Buffers,
but we do not, it is true, release the TextClass objects that are
associated with them. There's actually a good reason for that where
ordinary Buffers are concerned---there could be something on the cut
stack that still has a reference to the TextClass in question---but
in the case of AutoSave, there is no reason we need to keep these
around. See the comments at the end of TextClass.h, concerning the
DocumentClassBundle.
I'll try to have a look shortly, but classes start again on
Wednesday. If anyone else had ideas, I'd be happy to hear them.
Richard
We don't need a new TextClass everytime. If we already have one for
the documentclass/layout, we can reuse it again.
I'm afraid it's more complicated than that. I mean, in principle we
could do that, but the new TextClass (actually DocumentClass) object is
created in the BufferParams constructor. I think I have a good idea what
to do here, though. Minimally, we could delete the clone's DocumentClass
on destruction since we know that no-one else will have a reference to it.
This also means that with every preview we lose memory.
Yes, this is all an unforeseen consequence of the cloning business.
(Enrico strikes again!) But there are other places we create these
objects and never get rid of them.
Richard
