Description: Memory usage on file open 4 times higher compared to LibO6.1 Steps to Reproduce: 1. Open the attached file 2. Compare memory usage with 6.1 Actual Results: 280 MB Expected Results: 70 (or something like that Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.0.0.alpha0+ Build ID: b63d48a146c3615f56b6ec83361b3c02ebcbb215 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-13_23:33:20 Locale: nl-NL (nl_NL); Calc: CL but not in Version: 6.1.0.0.alpha0+ Build ID: c26f644db80e10f755911d277aac0e1d42731d29 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
Created attachment 145863 [details] Example file
My results - with LO 6.1.2 from Ubuntu PPA: 181 Mo - with LO 6.1.4.0.0+ built at home : 179 Mo - with LO 6.2.0.0.alpha0+ : 338 Mo It is not 4 times higher but the change seems very big and it suggests there's a bug. Set to NEW. Version: 6.2.0.0.alpha0+ Build ID: b9d06c893df399e16572381d086db42be12186eb Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Ubuntu_18.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Calc: threaded Best regards. JBF
Created attachment 145881 [details] Bibisect log Bisected to 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
Adding cc: to Miklos Vajna
Argh, nevermind.. Only happening with a very long single paragraph
(In reply to Telesto from comment #5) > Argh, nevermind.. Only happening with a very long single paragraph Shouldn't change things on sunday's. There is no single large paragraph.. Back to new again.. Sorry for the fuzz
Not sure if this should be reported here, but two additional observations: 1. Open the attached file 2. Switch to Print preview -> Memory drops and builds up again (possible explanation: SwFntObj gets cleared & rebuild) 3. Close the print preview -> Memory drops and builds up again --- 1. Open the attached file 2. Switch to print preview 3. Press Page Down -> Memory usage keeps increasing
I can reproduce the increasing memory usage, though the ratio is smaller here (about +-10% of memory usage after the import and layout finished). I'll look at this.
(In reply to Miklos Vajna from comment #8) > I can reproduce the increasing memory usage, though the ratio is smaller > here (about +-10% of memory usage after the import and layout finished). > I'll look at this. The ratio is indeed smaller. Not sure about how I end up with the initial finding Version: 6.1.0.2 -> 206 MB ersion: 6.2.0.0.alpha1+ -> 260 MB Build ID: 96cf06c947838120e37f3fbb4d0543dd882cb20c CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-25_22:57:51 Locale: nl-NL (nl_NL); Calc: CL Comment 7 is also reproducible (for me), but might be unrelated to bug report as such
Small update 1. File opening size of 70 MB is only possible in bibisect builds before aeff83240c88435d11590f5e9c6fe9927a508c6a after it's 280 MB. There seems to be an odd difference between release builds & bibisect builds anyway. Release builds: 6.1.0.2: 206 MB (no clue what would explain the difference) 5.4.0.1: 209 MB 5.3.0.3: 207 MB 5.3.0.0.beta2+: 97 MB 5.2.5.0.0+: 80 MB 4.4.7.2: 123 MB 2. I bisected the steps of comment 7 (scrolling down in print preview causes memory usage to increase rapidly, also to the same commit: aeff83240c88435d11590f5e9c6fe9927a508c6a
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/19a0698079fbba36646a2d06eaec3a7fde60b2f5%5E%21 tdf#120735 sw: clear the font cache text glyphs when layout finished It will be available in 6.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No backport, problem was master-only.
@Telesto, Could you please verify the fix with a master build? Thanks in advance
The issue is fixed in the strict sense, when looking at file open. However the issue still present: 1. Open the attached file 2. Wait until the memory drops to 175MB (fine) 3. Now hold page down until the end, memory usage is back to 294
Could you please file a separate bug for that? Would be interesting to see when *that* started happening, may be a different commit. Thanks!
(In reply to Miklos Vajna from comment #15) > Could you please file a separate bug for that? Would be interesting to see > when *that* started happening, may be a different commit. Thanks! I created a new report bug 121058. Setting this one back to resolved fixed. BTW, thanks for all the effort :-). I'm probably a bit of a pain in the ass, with all my bug reports surrounding the text layout performance
*** Bug 121019 has been marked as a duplicate of this bug. ***