Bug 121059 - Scrolling down in print preview causes memory usage to increase rapidly
Summary: Scrolling down in print preview causes memory usage to increase rapidly
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2018-10-30 13:22 UTC by Telesto
Modified: 2024-05-22 22:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-10-30 13:22:19 UTC
Description:
Scrolling down in print preview causes memory usage to increase rapidly

Steps to Reproduce:
1. Open the attachment 145863 [details]
2. Wait until loading is finished (CPU drops back)
3. Switch to print preview
4. Press Page Down -> Memory usage keeps increasing

Actual Results:
Memory usage keeps increasing

Expected Results:
Steady memory usage


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.0.0.alpha1+
Build ID: 2e184378da6058af14acf208d6469fadf44d04ed
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-30_03:29:39
Locale: nl-NL (nl_NL); Calc: CL

Bisected to (see bug 120735 comment 10)
author	Miklos Vajna <vmiklos@collabora.co.uk>	2018-08-31 18:19:12 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2018-09-03 09:13:32 +0200
commit aeff83240c88435d11590f5e9c6fe9927a508c6a (patch)
tree a3b918a7d3164ee428a4df39df7118a87618dfd9
parent 08b5048198d59441cb8033ed14cd17e68c943004 (diff)
sw: save more vcl layout calls in SwFntObj
This builds on top of commit 436b829f5b904d76039db0818cff5dedf1ae89f1
(sw: save one vcl layout call in SwFntObj::DrawText(), 2018-08-16), but
now layouts are shared not only inside SwFntObj::DrawText(), but also
between SwFntObj::GetTextSize() and SwFntObj::DrawText().

To get there, create an SwFntObj cache member that stores already
calculated vcl layouts. SwFntObj already derives from SwCacheObj, so no
need to explicitly expire this cache member.

Total number of GenericSalLayout::LayoutText() invocations go down from
8 to 5 with this when pressing a key in Writer.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=aeff83240c88435d11590f5e9c6fe9927a508c6a
Comment 1 Telesto 2018-11-06 11:44:43 UTC
@Buovjaga
Probably exaggerating the importance, but would you mind to take a look..
Comment 2 Buovjaga 2018-11-08 15:07:54 UTC
Yes, I confirm, but it is about caching after all and the memory increase stops when you reach the last page.
Comment 3 Buovjaga 2018-11-08 15:11:30 UTC
Why is this separate from bug 121058?
Comment 4 Telesto 2018-11-08 15:51:19 UTC
(In reply to Buovjaga from comment #3)
> Why is this separate from bug 121058?

1) Bug 121058 started after the "bugfix" for bug 120735. This issue was already present..
2) I'm not sure how the layout stuff works; so if there is a difference in code between print preview & normal layouting... (and extending it a bit: between print preview & PDF export). 
3) Miklos suggested that I should file a report (so bug 121058) because of of a different root cause (see comment 120735 comment 15). But I have nothing to go on (memory doesn't increase it's high all the time)

But I don't deny any similarity.. :-)

----
About "it is about caching after all". 

* It's the tricky part.. The bug fix for bug 120735 doesn't make much sense, if it's still happening scrolling down, except for complicating things.
* And it looks like there is to much caching going on... based on the commit for bug 120735 (but that's my reading) https://gerrit.libreoffice.org/plugins/gitiles/core/+/19a0698079fbba36646a2d06eaec3a7fde60b2f5%5E%21

---
How lovely layout caching is, the rather a memory hog.. And i'm really a fan:
* Potential for OOM on Windows 32x builds (with multiple documents)
* Quite a lot of users use legacy systems with limited ram (swapping to disk is painfully slow)
* Even pricey hardware (apple) still sold with only 8 GB
* What would it mean for LibreOffice online; doubling the server memory required? (not knowing much about server side.. so only speculation)
* Would look bad for the real life minimum system requirements 
* I don't like the idea of swapping one issue for a different one.
Comment 5 Xisco Faulí 2019-07-31 12:01:30 UTC
Hi Telesto,
Is this issue still reproducible in master ?
Comment 6 Telesto 2019-10-20 18:51:30 UTC
Repro with
Version: 6.4.0.0.alpha0+ (x86)
Build ID: c45d477b0a0038d9c25176cf7cff299e5ddf3a7a
CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-09-30_05:06:55
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 7 Carlo 2021-09-29 21:47:24 UTC
Duplicated?
See https://bugs.documentfoundation.org/show_bug.cgi?id=121058#c4
Comment 8 Telesto 2021-09-29 21:54:06 UTC
(In reply to Carlo from comment #7)
> Duplicated?
> See https://bugs.documentfoundation.org/show_bug.cgi?id=121058#c4

The big question: I reported those intentionally as separate bugs, because I'm not 100% sure. Have seen enough bug looking the same, but being different in the sense of hitting slightly different area of code.
Comment 9 QA Administrators 2023-09-30 03:17:45 UTC Comment hidden (obsolete)
Comment 10 Steve271 2024-05-22 22:23:05 UTC
I can confirm that the bug is present in:

Version: 6.4.7.2 (x64)
Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL


This bug is no longer reproducible in

Version: 7.6.7.2 (X86_64) / LibreOffice Community
Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

I have also tested(on windows) in versions: 24.2.2.2 and 24.8.0.0.alpha1+
and the bug is not reproducible in those versions.

Changing status to RESOLVED WORKSFORME