Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.