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
@Buovjaga Probably exaggerating the importance, but would you mind to take a look..
Yes, I confirm, but it is about caching after all and the memory increase stops when you reach the last page.
Why is this separate from bug 121058?
(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.
Hi Telesto, Is this issue still reproducible in master ?
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
Duplicated? See https://bugs.documentfoundation.org/show_bug.cgi?id=121058#c4
(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.
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug