Bug 152571 - Very slow save (macOS, ARM)
Summary: Very slow save (macOS, ARM)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.5.0.0 beta1+
Hardware: ARM macOS (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.0 target:7.6.4
Keywords: perf
: 157582 (view as bug list)
Depends on:
Blocks: Save MacOS-Performance
  Show dependency treegraph
 
Reported: 2022-12-17 18:05 UTC by Jeff Potter
Modified: 2024-01-25 07:57 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Graphs of time profile trace indicating hangs (152.19 KB, image/png)
2023-10-23 10:22 UTC, Alex Thurgood
Details
Time Profiler trace on loading file (14.47 KB, text/plain)
2023-10-23 10:37 UTC, Alex Thurgood
Details
Time profile trace on saving file after single character edit in text box. (19.80 KB, text/plain)
2023-10-23 10:45 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Potter 2022-12-17 18:05:21 UTC
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
Comment 1 Alex Thurgood 2023-01-02 09:38:43 UTC
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 ?
Comment 2 Alex Thurgood 2023-01-02 09:40:17 UTC
I would also suggest trying to reproduce with the latest 7.5 release (7.5.0.1 (AARCH64).
Comment 3 Jeff Potter 2023-01-03 01:39:04 UTC
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.
Comment 4 QA Administrators 2023-01-03 03:19:15 UTC Comment hidden (obsolete)
Comment 5 Stéphane Guillou (stragu) 2023-10-06 12:27:26 UTC
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!
Comment 6 Alex Thurgood 2023-10-06 21:30:02 UTC
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.
Comment 7 Sierk Bornemann 2023-10-06 22:15:12 UTC
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
Comment 8 Alex Thurgood 2023-10-07 08:40:43 UTC
(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.
Comment 9 Stéphane Guillou (stragu) 2023-10-18 07:05:08 UTC
*** Bug 157582 has been marked as a duplicate of this bug. ***
Comment 10 Stéphane Guillou (stragu) 2023-10-18 07:15:47 UTC
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?
Comment 11 Alex Thurgood 2023-10-18 18:41:48 UTC
(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.
Comment 12 Stéphane Guillou (stragu) 2023-10-21 14:22:07 UTC
(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.
Comment 13 Alex Thurgood 2023-10-23 10:20:42 UTC
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.
Comment 14 Alex Thurgood 2023-10-23 10:22:18 UTC
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.
Comment 15 Alex Thurgood 2023-10-23 10:37:36 UTC
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.
Comment 16 Alex Thurgood 2023-10-23 10:45:03 UTC
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.
Comment 17 Commit Notification 2023-10-27 20:04:11 UTC
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.
Comment 18 Michael Meeks 2023-10-28 17:10:27 UTC
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 ? =)
Comment 19 Alex Thurgood 2023-10-30 11:53:21 UTC
(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
Comment 20 Noel Grandin 2023-11-01 10:52:54 UTC
(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.
Comment 21 Commit Notification 2023-11-03 16:00:48 UTC
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.
Comment 22 alf.hamann 2023-11-22 16:03:32 UTC
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
Comment 23 alf.hamann 2024-01-15 12:00:49 UTC
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...
Comment 24 alf.hamann 2024-01-15 12:06:02 UTC
*** Bug 157582 has been marked as a duplicate of this bug. ***