Hi Michael, On Wednesday, 2014-12-31 10:48:48 +0000, Michael Meeks wrote:
I knocked up the attached patch - assuming that we don't really use that Listener nearly as much with the new FormulaGroup listener magic - but ... it turns out that this increases memory usage:
Not to much surprise ;-) IF broadcasters are used frequently, the separately new'ed instances add overhead for the heap allocation as then for each allocation also the allocation structure is allocated. The sc::FormulaGroupAreaListener singles out listening to a range/area that is identical in a group of formulas, not to individual cells, which may differ for each formula in a group. If the ScFormulaCell instances were still allocated from the shared mempool we'd also have slightly less allocation overhead with the current code, but that is unrelated to the observation made here. Since introduction of #ifdef USE_MEMPOOL in sc/inc/formulacell.hxx and sc/source/core/data/formulacell.cxx the shared mempool is disabled. Why anyway?
I suspect that we are pushing an entry into it currently for every single-cell reference.
Yes.
My hope is that having a single-cell group listener construct for this would mean that my tweak might actually work & save a ton of that duplication / memory allocation. But that's for the future I guess.
Only if absolute references are used.
Other things that look a bit wasteful are:
ScFormulaCell* pPrevious;
ScFormulaCell* pNext;
ScFormulaCell* pPreviousTrack;
ScFormulaCell* pNextTrack;
At least one pair of these (IIRC the 'Track') are needed only
transiently during calculation as an append-only list and could be
reasonably easily replaced by a bool bit-field and a std::vector on the
ScDocument itself - which would save 48Mb or so (on 64bit).
True, a cell can be only in either the Track or the Tree, not both, so reserving 4 pointers for this is waste now. A vector would be most awkward as removing cells from any position and growing/shrinking the track and tree frequently is necessary, so a double linked list for each, the Track and the Tree, probably would be best. Which per cell would save 2 pointers and add 2 booleans, given memory alignment we might save 4 to 7 bytes per cell and had to rewrite the tracking and cell maintenance code and access track/tree elements through the container's iterators with performance penalty. I'd rather get rid of 2 pointers and add 2 booleans and not add any container to the document, which still would save 4 to 7 bytes per cell, until/unless we're going to implement least recalculation paths in some tree structure that could be calculated independently of each other. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
pgpxGEVxD9S6Z.pgp
Description: PGP signature