Description: Memory after third opening 280 MB expected 130 MB Steps to Reproduce: 1. Open attachment 97742 [details] (bug 77519) 2. Close 3. Repeat 3x and look at memory usage for start center at the third time Actual Results: 280 MB Expected Results: 150 MB Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: a35c18aeff3b1d8f270db7e094850fb8ba1ab84a CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in Version: 6.4.0.0.beta1+ (x64) Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL I hope I'm repeating myself: weldfontbox.. bug 132536
I tried to reproduce on Windows 10 and debian with 7.0 beta 1 and could not reproduce. - Could already been corrected (please check). - Be more specific about your system. - (note: I'm not a pro)
I repro, but why open this when bug 132536 still does not have a solution?
(In reply to Buovjaga from comment #2) > I repro, but why open this when bug 132536 still does not have a solution? Because I'm using the bugtracker as reminder to look at it some time; I probably forget it.. at some point. And because I'm getting slightly impatient.. * While testing bug I end up with 1/2 GB ram used.. with documents of 15 pages in around 15 minutes.. I can only assume.. its the font cache, it's font cache.. but never knowing for sure.. maybe another change.. * Font cache is tricky area.. Developers tend to walk around it for years. And Khaled wasn't to happy with it either (and struggled to understand how it worked).. So I assume the font cache to be a quite a thing; even for experienced developers. Which makes me even more worrisome. And I connecting this with the work of M. Stahl on tables, solve 1 problem, get 2 back. Solve two problems get 4 back.. Or Jmux starting to fiddle with timers, madness appears everywhere (re-resurrecting old hideous bugs etc). So I'm assuming the worst case.. until I'm proven wrong... Especially with fonts/ font measurements being cached/used on different levels. Harfbuzz Internal/ LibreOffice itself?/ the layout cache of Miklos.. all relaying on font lifetime cycles etc. Different font handling between OSes.. So enough potential to go wrong. It started already with welding the Fontbox; adding of a new special rendering; removing a few font caches.. This type of rework you ideally plan in advance to do, not something you want to resolve as side effect of welding; Ideally at the beginning of a new release, not at the point of beta2 or RC1... And a developer delaying to look at - I assume so; can't proof, maybe looking at it in silence - it doesn't give me much confidence. I don't associate Caolan in addition with font handling in general (more the expertise of Jmux/Khaled) and/or developing on Windows. Caolan has tons of experience... so maybe underestimating (hope so) but I don't see it as his area of expertise (or interest?). Especially if the font cache code being broken all over the place.. So fiddle with A and B does something unexpected. Fiddle with C and D does something it shouldn't do. Fiddle with E, expect G and get Z. I'm too pessimistic, I hope..
I tested with Linux 6.5 repo and indeed before the weldfontbox commit the memory use was reset after each close/open cycle. So I don't know - it seems impossible to determine at this point, if this issue is separate. It would be masked behind the remaining issue.
Reproduced. Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: cd2b5168e8ef1cb6e721bc5220421464ed723096 CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-21_14:56:23 Calc: threaded