Description: 2 GB of ram used when clicking open new calc document 10 times Steps to Reproduce: 1. Open LibreOffice 2. Launch Calc from Start Center 3. Press new document button 9 times. 4. Check ram usage 4. Press close button for all Windows. When back at start center check ram usage Actual Results: +/- 2 GB with 10 windows 850 mb after close Expected Results: 800 mb with 10 windows 600-700 after close Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ba8f4bff6015013013df652efbfaf4d9ae10c881 CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
On Windows: 567 mb for 10 windows with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 25276df12abd9d002f7f899900434617b256f745 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 threaded 345MBB for 10 windows with Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 35f19e5cb93ce218787904e99c2bedfd40e725cc 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 threaded 370 MB with for 10 windows with Version: 7.3.8.0.0+ (x64) / LibreOffice Community Build ID: e1ad83ddb2f39419fb5d7c69eba51e2b9f49c788 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 555 mb for 10 windows with Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a 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
1,7 gb with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 383e68da6c429c243c1e7be6699acaa942b712bc CPU threads: 8; OS: Mac OS X 13.6.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded 1,53 with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1cfeb4bd8ce7f7727a81136bd3e2d6ebea976895 CPU threads: 8; OS: Mac OS X 13.6.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded 816 mb with osx and 1,09 gb with skia raster using Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Mac OS X 13.6.3; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded 1,1 GB with Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Thank you for reporting the bug. I can not reproduce the bug in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 861e83d1e74a718462ba524695cfa6ccb13bf7db CPU threads: 6; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: CL threaded
I have to recheck this...
[Automated Action] NeedInfo-To-Unconfirmed
Hi, Thanks for reporting. I have try to replicate the bug but no bug was present of 2 GB used. I originally have 9.4 GB available. I only found that the 10 documents opened only used 0.2 to 0.3 GB (~230 mb). Version: 24.2.0 (x86-64) Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 TinderBox: Windows 10 Pro, LibreOffice 24.2
Well leaking is present.. however it's less simple. A) Comment 0 might require a profile modified by an 'old' version of LibreOffice. 7.6 I think. With certain content, unable to trigger it from scratch right now. LibreOffice in safe-mode is somewhat illustrating the issue when creating 10 windows B) Xcode Instruments does detect leaking creating new documents, in normal mode C) Resetting profile by starting in safe mode, checking reset entire profile and restart does cause a massive leak at first launch
Still a memory hog when having 10 empty calc spreadsheets open Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aaf2967d74a9a7ba2d28433e1872422ce38b6244 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Memory usage improves without Skia (shaves off 600-700 mb). It still more compared to what I would expect from couple of blank spreadsheets. Not sure if Skia is only exacerbating some underlying (paint?) issue or if multiple issues being stacked on top of each other. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aaf2967d74a9a7ba2d28433e1872422ce38b6244 CPU threads: 8; OS: macOS 14.3; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
@Patrick You might be interested in this one. Calc memory usage for black sheets rather excessive, IMHO. A non-issue with plenty of RAM. However Apple makes it a quite expensive upgrade
Created attachment 194758 [details] Snapshot of Instruments applications with Allocations List sorted highest to lowest Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: fab293ebc59c583f4cd17a6802f7d538b6b53556 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to Patrick Luby (volunteer) from comment #11) > Created attachment 194758 [details] > Snapshot of Instruments applications with Allocations List sorted highest to > lowest > > Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community > Build ID: fab293ebc59c583f4cd17a6802f7d538b6b53556 > CPU threads: 8; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx > Locale: en-CA (en_CA.UTF-8); UI: en-US > Calc: threaded So I ran the Instruments application's memory leak tool against my local debug master build. I launched LibreOffice, and started tracking in Instruments when the Start Center appeared. Then, I open 10 empty Calc documents and stopped tracking in Instruments. I found no big memory leaks, but memory usage when I stopped tracking in Instruments was over 2 GB. So I sorted the "Allocations List" to see the highest memory allocators as shown in the snapshot in attachment #194758 [details]. Not surprisingly, the highest allocators look like they are bitmaps and/or drawing surfaces for each window. Not sure what all this data points to yet. But what seems odd to me is that all of the highest allocators are a lot larger than I expected. Window sizes during my test were roughly 1500 x 1000 pixels. Double both and multiply for Retina display (i.e. each Retina pixels is really 4 pixels) and by 4 since each pixel is 32 bits and, if my math is correct, I would expect to see roughly 24 MB for each window's internal backing bitmap or roughly 240 MB for 10 windows. Double that to 480 MB because LibreOffice has its own backing bitmap for each window. So I can account for roughly 0.5 GB of the memory usage by see 2 GB of total memory usage. When I get some time, I think the next step that I need to do is figure out what is in the remaining 1.5 GB of memory usage.
Created attachment 194810 [details] Debug patch that limits CGLayers and their underlying CGBitmaps to only 1x1 pixels
(In reply to Patrick Luby (volunteer) from comment #13) > Created attachment 194810 [details] > Debug patch that limits CGLayers and their underlying CGBitmaps to only 1x1 > pixels After some time looking through the leak detection output in the Instruments application, I noticed that several hundred MB of memory was allocated for CGLayer and CGBitmap instances even though I was using Skia/Metal. Skia/Metal and Skia/Raster have their own equivalent offscreen drawing surfaces so I would think that those instances would only be used when Skia is disabled. So I used the debug patch in attachment #194810 [details] to limit CGLayer and CGBitmap instances to 1 x 1 pixels. Running LibreOffice from my local master build with the debug patch dropped maximum memory usage by 2/3 for both Skia/Metal and Skia/Raster. Apparently Skia/Metal does not need these native instances and everything is drawn normally with the debug patch. Skia/Raster, however, draws only a single pixel with the debug patch so it still needs the native instances. So, the next step is to see if I can figure out why Skia/Raster needs those native instances.
(In reply to Patrick Luby (volunteer) from comment #14) > (In reply to Patrick Luby (volunteer) from comment #13) > Running LibreOffice from my local master build with the debug patch dropped > maximum memory usage by 2/3 for both Skia/Metal and Skia/Raster. Thanks for the in between post. Quite an improvement if achievable; I'm looking forward to the patch. The result might even be (a bit) better for non-debug build
I was able to get Skia/Raster to eliminate creating CGLayer instances in the following patch: https://gerrit.libreoffice.org/c/core/+/169242 With the above patch, I am seeing a 1 GB reduction in the "allocations" graph in Instruments with both Skia/Metal and Skia/Raster when I open 10 empty Calc documents. I think there are some minor inefficiencies when we don't need to update a whole window handle such as when in Writer the cursor blinks so I'll take care of those before I commit the above patch.
(In reply to Patrick Luby (volunteer) from comment #16) > I was able to get Skia/Raster to eliminate creating CGLayer instances in the > following patch: > > https://gerrit.libreoffice.org/c/core/+/169242 So I think that I have completed the above patch and I am waiting for the patch to pass all unit tests before I commit it. What I found is that when using the "leaks" tool in the Instruments application and I open 10 empty Calc documents, the peak memory usage in the "Allocations" graph changes as follows: Without patch With patch Net reduction ------------- ---------- ------------- Skia/Metal 1.5 GB 0.5 GB 1.0 GB Skia/Raster 3.0 GB 1.5 GB 1.5 GB Skia disabled 3.5 GB 3.5 GB None In both cases, the reduction in memory usage per window when using Skia is quite significant. I assume that Skia/Metal is significantly lower than Skia/Raster since the drawing surface is in GPU memory instead of CPU memory. Note: I didn't make any changes to the "Skia disabled" code. There might be some possible memory usage reductions that I can do there but I haven't looked too deeply at that old code yet. But it is interesting how much less memory Skia needs in comparison to the old non-Skia code.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/12dbf0e6b6b485a1d73c7e33bd0ecfb13e6efdac tdf#159175 Do not allocate a CGLayer for each NSWindow when using Skia It will be available in 25.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.
I have committed a fix this bug that should reduce memory usage significantly when using Skia/Metal or Skia/Raster (see comment #17 for what reductions I see with the fix). The fix should be in tomorrow's (26 June 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Looking good. +/- 1 GB with 10 open Calc windows with skia raster Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9c1a48f844eaefc505a5914338b6f444011bf315 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Hi. When will this patch be officially available for Apple Silicon users and what is the release number? Thanks.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/5b58bc4735e0ec76f9c9dd0ecb047cb662937508 tdf#159175 Do not allocate a CGLayer for each NSWindow when using Skia It will be available in 24.2.5. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/f73f91a65887f58147dd3dd7619c3bd5aa15495c tdf#159175 Do not allocate a CGLayer for each NSWindow when using Skia It will be available in 24.8.0.0.beta2. 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.