Description: Memory usage still high after presentation has ended Steps to Reproduce: 1.Open the attached file (and take task manager to see memory usage 2.Press F5 3. Press and hold Enter -> until different sheet set starts 4. Click around few other slides Actual Results: 950 - 1 GB memory usage.. even after presentation has finished Expected Results: 500 or Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Created attachment 170378 [details] Example file
LO doesn't drop unused memory in this case. Confirm in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 9d8accf03984a64a4105826e55b221962628eb93 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL LO use a 650 mb of memory even after closing Impress instead about ~200 mb. I'm not sure, but may be it's a inside LO's cache works so...
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
Reproduced in daily master build. - Opening file in Impress took up around 200mb. - After exiting slide show (I did not click through full slide show), memory was around 730mb, then dropped to 690mb and remained there. - Closing Impress returned memory around 200mb. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 486ae5db6987411d5e394de94b2b077099d03856 CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Not reproducible in 3.3 (memory remained around 120-140mb), so this is a regression.
(In reply to Telesto from comment #0) > 3. Press and hold Enter -> until different sheet set starts I assume what you wanted to say is until slide 69. Testing with old repos, oldest of linux-41max already shows a ~100 MB increase remaining. Oldest of bibisect-43all repo (3.5), shows only a ~20 MB increase remaining. However, last36onmaster and last40onmaster tags in the repo both crash upon starting the slideshow, so I doubt this is bibisectable. Doing `git checkout HEAD~100` from last36onmaster shows the "good" memory increase, so the change happens somewhere around 3.6 and 4.0. As comment 2 hints, of course it's debatable whether this is a real issue at all. Caching is not a crime and the resources on your computer are there to be used.
Still here. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 09a48f45d9a3e72ab761e6808701362c9c0b2e51 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded The 100% for a 1 CPU si moving to 50% on 2 CPU, then again 100% on 1 CPU and so on... Even closing the document and the CPU is up.