ScFormulaCell size foo ...

[Eike Rathke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150102/ba7842ec/attachment.sig>