Description: Noticeably slower performance while opening and saving simple Writer files. Disk icon turns red, screen pretty much freezes. Progress wheel starts whirling just long enough to make me think it's frozen. Steps to Reproduce: 1. Change your file 2. Hit command-s to save. or 1. Open file. Actual Results: Slow performance as described above. Expected Results: In previous versions of Writer, saving simple files locally on the same fast drives was virtually instantaneous. Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Mac OS 12.6.1 OS is 64bit: (I believe it is, right?) Version: 7.5.0.0.beta1 (AARCH64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 8; OS: Mac OS X 12.6.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
No repro for me with Version: 7.5.0.1 (AARCH64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Tested with a newly created Writer document, typed 2 lines of text, pressed "Cmd-S", chose "Download" folder as destination, left "Untitled1.odt" as the default, pressed OK. The document saved quasi-instantaneously. Was there anything particular about your document ? Links, graphics, formulae, other objects, volume, destination folder for save ?
I would also suggest trying to reproduce with the latest 7.5 release (7.5.0.1 (AARCH64).
The files I edit are generated by a PHP script that merges data into an .odt template, but I've been using this script for 12 years and haven't had this issue. The text could not be simpler. I have installed and tested 7.5.0.1 and found it sluggish (a term that I know is hard to quantify) but much improved.
[Automated Action] NeedInfo-To-Unconfirmed
Jeff, are you able to test again with the latest 7.5.7.1 version? I see a similar complaint in the App Store reviews, back in June 2023, on a Mac mini M2. Thank you!
Fwiw, I am now experiencing the same poor performance, spinning beach ball, mouse response lags, laggy UI, etc, with Draw and LO7621, on M1 macOS Sonoma. It really is very frustrating and infuriating for LO to be afflicted in this way.
I can't reproduce the issue in question. (In reply to Alex Thurgood from comment #6) > Fwiw, I am now experiencing the same poor performance, spinning beach ball, > mouse response lags, laggy UI, etc, with Draw and LO7621, on M1 macOS > Sonoma. It really is very frustrating and infuriating for LO to be afflicted > in this way. I can't reproduce this either. Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 10; OS: Mac OS X 14.0; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 06b7a31cbe971470b5551044efc6c977b44bc312 CPU threads: 10; OS: macOS 14.0; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
(In reply to Sierk Bornemann from comment #7) > I can't reproduce the issue in question. > > > I can't reproduce this either. > It is very strange indeed. I'm going to experiment some more to see whether it is Skia related, as I've had other issues with other parts of LO due to Skia being activated by default. I'll see if I can run an Instruments trace against a running LO, it might show something.
*** Bug 157582 has been marked as a duplicate of this bug. ***
Hm, wondering now if there are two issues here. - Jeff, have things improved in 7.5.7? - Alex, do you think you are seeing the same in 7.6.2 as in bug 157582?
(In reply to Stéphane Guillou (stragu) from comment #10) > Hm, wondering now if there are two issues here. > > - Jeff, have things improved in 7.5.7? > - Alex, do you think you are seeing the same in 7.6.2 as in bug 157582? @Stéphane: for me, the problem isn't on first save. Every save operation causes the spinning beach all, even after minor changes to a Draw file.
(In reply to Alex Thurgood from comment #11) > @Stéphane: for me, the problem isn't on first save. Every save operation > causes the spinning beach all, even after minor changes to a Draw file. I understand that's the same as in bug 157582.
I ran a time profile of daily dev master build (x86_64) on macOS M1 Macbook Pro, with a copy of a Draw file I'm working on (not provided, as it is a privileged work product). The attached screenshot displays what the Instruments.app tracer deems as hang, sever hang, or micro hang. What I did here was: 1) Loaded the Draw file into soffice. 2) Started the Instruments app, attacehd to the running soffice proces, and then started the time profiler module. The screenshot attached shows the result of Run N°3 as detailed below: 3) Made a single change to a textbox in the Draw file, by editing the content of the textbox, and inserting new content into the text box. This change involved replacing a single character (the number "5" for the number "2"). 4) Saved the Draw file. Note how there is more than one severe hang in just 44 seconds of profile tracing. I also have the saved trace file, but it uses the macOS trace format, which is essentially a 12Mb zipped file full of lots of verbose crud and some potentially useful information that you have to hunt down.
Created attachment 190384 [details] Graphs of time profile trace indicating hangs These graphs and information are provided by the Apple Instruments app running against soffice after having loaded a sample Draw file, and making a single change to a text box, and then saving the Draw file.
Created attachment 190385 [details] Time Profiler trace on loading file This is a copy paste of the time profile trace for the first severe hang event in the time profiler.
Created attachment 190386 [details] Time profile trace on saving file after single character edit in text box. This is screen copy / paste details of the time profile on saving after a single character change to the Draw file.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d86a0b632813efb2259b795b272f8aa40a7c768 tdf#152571 speedup slow draw file save It will be available in 24.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.
Why do we bother with the checksumming ? =) Surely when we save we just dump the PNG data we have from disk to zip file - but if we save time here fine; I'm just curious as to why we bother CRC'ing. Is it possible we had that at load (can we get it from the zip?), but then we swapped and (somehow) then bogusly forced a re-calculate of the CRC on swapping back in or ? =)
(In reply to Commit Notification from comment #17) > 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. Seems to have fixed the problem, at least with my test Draw document, thanks Noel! Tested on Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 31fb3045dabdb27d913712f3abcade315e3ea9bd CPU threads: 8; OS: macOS 14.0; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
(In reply to Michael Meeks from comment #18) > Why do we bother with the checksumming ? =) Surely when we save we just dump Oh yes, there is definitely at least one more bug here, but fixing that would require being able to reproduce the issue, which at least I, cannot.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/d9f2b74241eb6136db767ec56c10be1cc0292599 tdf#152571 speedup slow draw file save It will be available in 7.6.4. 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 previously reported a similar or same bug, as mentioned in this chat (https://bugs.documentfoundation.org/show_bug.cgi?id=157582). I want to inform you, that after updating Mac OS to Sonoma, OS 14.1.1, the problem disappeared (without touching LibreOffice). Configuration: Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Mac OS X 14.1.1; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: thread
Unfortunately, my message that the bug is gone with update of MacOS was premature. It was the case directly after updating, but now, some weeks later, the bug again appears. Also after installing the new 7.6.4.1 release of LO...