On 02/13/2013 09:34 AM, Rob Weir wrote:
On Tue, Feb 12, 2013 at 6:47 PM, Andrew Douglas Pitonyak
<and...@pitonyak.org> wrote:
If you have a good setup for testing such things, try loading, saving, and
closing AndrewMacro.odt
That's a big one: Release the Kraken!
The time to close the document (not saving) could be low-hanging
fruit. Presumably there is a free of a huge data structure to reclaim
the heap. It would be interesting to see how many times we call free.
When we had a similar problem in SmartSuite (many years ago) we solved
it by using a custom memory allocator (overriding operator new). For
allocations we managed our own heap, keeping related data structures
together. I don't know if it is still a benefit today, but back then
"locality of reference" was a big thing when it came to memory paging
and caching. In any case when it came time to free the document, we
did it trivially. Instead of doing the zillion free's to clean up the
document data structures we called the global delete operator on the
entire memory buffer, cleaning it up in a single call.
The downside was this confused any tooks we used to look for memory
leaks. Most of them looked at heap-level allocations and frees and
reported a mismatch. So we had a debug version of the library as
well, that was slower but did the memory management more
traditionally. And we used the faster version for QA and production.
-Rob
Yeah..... The document has so many style changes that it crashed OOo
(because of limitations of one or more internal list). I would love to
see what is really going on there.
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
