[Libreoffice-bugs] [Bug 133667] Memory usage increases with 20 MB style setting font change and closing the document doesn't free the memory

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=133667

--- Comment #5 from Telesto <telesto at surfxs.nl> ---
(In reply to Miklos Vajna from comment #4)
> We have a speed vs memory usage trade-off here. As far as I see, the code we
> have today has a short-time cache, cleared at the end of each layout run.

Is possible explain this a bit more in detail, what the 'cache' does. What a
layout run triggers. And when the layout run ends.. 

I would expect it for
-> File open
-> Export to PDF
-> Change to multi page view 
-> Going to PrintPreview
-> Export EPUB

Does this also happen when?
-> Saving odt/docx/doc?

Is the layout cache also used while editing a large document? New paragraphs
added, pages move down etc.. I would expect lots of layout runs (but maybe i'm
wrong). Or has this nothing to do with the cache. 

---
And more for me understand memory management a bit better. If more memory is
needed new memory is allocated (on the heap or how is called). However the
memory is never - properly - de-allocated (when it's not needed anymore).. at
least that my impression. So PDF export means allocated memory to go up (more
memory being allocated, fine). However it does not come down (de-allocated)
after export is finished. Run the PDF export again.. memory usage stays the
same (not up/or down)

Same holds for opening/closing documents. Opening a document, memory goes up,
closing a document.. memory doesn't get fully de-allocated - it will drop with
75% or more.. but not all. Opening a new document.. and memory usage stays the
same.

There are of course more variables at work.. loading of the dictionary/ fonts
etc..). And maybe timer based flushes (at least Calc does this sometimes), but
still have the impression something being off. This not a recent phenomena.
Even seen in 4.3.7.2. However increased (it's or font cache handling (currently
bug 132536) or layout caching or image handling (bumping the cache size in
5.2))/ changes in (for example) PDF export code)

However, sometimes I question.. is the cache size of 5.2 still there? After
6.1, image handling rework? I think assume it is.. And if so, is it still
needed in the same way it was needed for 5.2. The image handling has improved
with 6.1 and Skia buffers large images to some extend (instead of scaling it on
every scroll; causing a bad performance). So cache can maybe reduced (now or if
Skia is more 'common)? Question I don't have the answer to. Increasing the
cache (for images) in 4.3/4.4 and in 5.2 was an easy/cheap work around for more
complex underlaying issues. Maybe solved over the years and not needed anymore
in the same extend.. [or I'm I breaking large GIF rendering with this proposal
;-)]. And/or I'm masking a more technical release image from memory issue with
the new system build into 6.1. Or missing the point how it works; who knows.. 

I'm certainly aware this isn't easy to solve; it's even easy to track down.. or
report.. with all those incremental changes over the last 5 years or so. I'm
having a list of say 6-10 bugs which actually are one package.. the are tied
and knotted together; and cumulative a problem, but separately not really so..
And appears in different shapes and figures.. Central topics around memory
usage are IMHO: Image handling/font handling/ sw layout cache (but probably not
a real surprise). So image handling and PDF export; Image handling and ODT save
(a clear cache image call for ODT save has been removed in 4.4; with the
assumption of being fixed by better function cache; not so). And maybe with
some issues being actually inherited.. but always masked by the way it was
used.. so maybe the image handling cache before 6.1 had some issues.. which
never been detected with the image handling cache being set to 'low'. 

So, released my insights. Cleared my head. Hope being useful somehow

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200615/f0c3cf58/attachment.htm>