Bug Hunting Session
Bug 106154 - Extremely slow basic operations on macOS
Summary: Extremely slow basic operations on macOS
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All Mac OS X (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
: 116730 (view as bug list)
Depends on:
Blocks: MacOS-Performance
  Show dependency treegraph
 
Reported: 2017-02-23 11:49 UTC by Adomas Venčkauskas
Modified: 2018-05-28 10:54 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
A video showing the issue (7.71 MB, video/quicktime)
2017-02-23 11:50 UTC, Adomas Venčkauskas
Details
IRC logs describing the problem (4.29 KB, text/plain)
2017-04-15 17:13 UTC, William Gathoye
Details
Issue not fixed in LO 5.4.0.3 (4.63 MB, video/quicktime)
2017-09-28 15:04 UTC, Yannick.D
Details
Time Profile from Apple Instruments (5.39 MB, text/plain)
2017-10-20 15:28 UTC, Alex Thurgood
Details
Complete Instruments Time Profile trace (5.30 MB, application/zip)
2017-10-20 15:46 UTC, Alex Thurgood
Details
Bibisect log (2.85 KB, text/plain)
2018-04-04 20:08 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adomas Venčkauskas 2017-02-23 11:49:08 UTC
Description:
LibreOffice Writer on MacOS Sierra responds extremely slowly for some basic operations. Right-Clicking and opening Character..., Paragraph... or Bullets and Numbering... dialogs take well over 5 seconds.

Steps to Reproduce:
1. Open LibreOffice Writer on MacOS Sierra
2. Right-click, choose "Paragraph..."
3. Wait for over 5s for the UI to show up

Actual Results:  
UI takes a long time to show up

Expected Results:
Should show up pretty much immediatelly


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Comment 1 Adomas Venčkauskas 2017-02-23 11:50:47 UTC
Created attachment 131430 [details]
A video showing the issue

This happens on a 2014 MacBook Pro with plenty of resources to respond fast.
Comment 2 Albert Wiedemann 2017-02-23 15:45:02 UTC
The same ist true for LibreOffice Draw, especially entering and leaving a text field takes several seconds (did not take any visual time in 5.2)
Comment 3 Alex Thurgood 2017-02-27 08:19:55 UTC
Confirming with

Version: 5.3.0.3
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 2; OS Version: Mac OS X 10.12.3; UI Render: default; Layout Engine: new; 
Locale: fr-FR (fr_FR.UTF-8); Calc: gr

It takes approximately 5s for the context menu to display, then 10 more seconds for the Paragraph dialog to be displayed on my mid-2010 Mac mini.
Comment 4 William Gathoye 2017-04-15 17:12:40 UTC
Hi there.

I'm impacted by this issue as well. Michael Meeks from Collabora answered to me they were aware of this issue which is basically due to the "mail-loop thread/idle handler re-work - which is a straggling thing that is ongoing".

Also, it would require a few thousands EUR/USD to fix the issue as the latter is quite complex.

It also appears this is a regression as this is reported to work fine under 5.1.x, the problem seems to have appeared somewhere in 5.2.x.

See a copy of the IRC logs attached for more details.
Comment 5 William Gathoye 2017-04-15 17:13:30 UTC
Created attachment 132593 [details]
IRC logs describing the problem
Comment 6 Buovjaga 2017-04-23 17:29:59 UTC
There is slowness on all platforms when opening cell formatting dialog in Calc: bug 98132
Comment 7 Andreas Borutta 2017-05-22 10:17:25 UTC
Confirming with 

5.3.3.2
Build-ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU-Threads: 4; BS-Version: Mac OS X 10.12.4; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 8 Yannick.D 2017-09-11 22:51:01 UTC
Still present in Version: 5.4.0.3
Build-ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU-Threads: 4; Betriebssystem:Mac OS X 10.12.6; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

This is to the point where LO on Mac is basically not usable anymore. I would set this report to critical and even consider (temporarily) stopping support for Mac OS entirely if this can't be dealt with.

Extremely slow UI as described above: scrolling skips tons of frames, dialogues take seconds to load [Bug 106154, Bug 106703, Bug 107113], completely unresponsive UI for seconds [Bug 106958], sometimes the GUI doesn't respond to system interactions anymore. Very frustrating and getting worse with complex documents (see Bug 104716, not related to Mac OS).

I tried to record a screencast but its a huge file and doesn't add much value. My experience is this: LO 5.3 and 5.4 have extremely slowly opening dialogues (spinning wheel all the time) and horrible scrolling performance; LO 5.2 ("Vanilla" App Store Version in my case) feels more fluid but has unpredictable UI freezes up to several minutes (!!) (mostly on opening list boxes like font size). (OOo 4.1.3 for reference feels fast in comparison but crashes randomly for me.)

I can confirm this on a 2015 MacBook, a 2009 and 2011 MacBook Pro running Sierra or El Capitan. I rely on LO for work and this is getting worse with each release instead of better. Actually its not sustainable anymore but there is no clear alternative. Sorry for getting personal but I'm certainly not alone with this, see (other than bug reports) https://ask.libreoffice.org/en/question/57739/anyone-finding-libreoffice-slow-on-osx/, https://ask.libreoffice.org/en/question/79342/libreoffice-extremely-slow-in-mac-os-sierra/.
Comment 9 Cor Nouws 2017-09-13 09:47:35 UTC
(In reply to Yannick.D from comment #8)
> Still present in Version: 5.4.0.3
> Build-ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
> CPU-Threads: 4; Betriebssystem:Mac OS X 10.12.6; UI-Render: Standard; 
> Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
> 
> This is to the point where LO on Mac is basically not usable anymore. I
> would set this report to critical and even consider (temporarily) stopping
> support for Mac OS entirely if this can't be dealt with.
> ...

@xisco: something you may want to look at or discus?
Comment 10 Yannick.D 2017-09-14 13:29:00 UTC
(In reply to Cor Nouws from comment #9)
> (In reply to Yannick.D from comment #8)
> > Still present in Version: 5.4.0.3
> > Build-ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
> > CPU-Threads: 4; Betriebssystem:Mac OS X 10.12.6; UI-Render: Standard; 
> > Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
> > 
> > This is to the point where LO on Mac is basically not usable anymore. I
> > would set this report to critical and even consider (temporarily) stopping
> > support for Mac OS entirely if this can't be dealt with.
> > ...
> 
> @xisco: something you may want to look at or discus?

I just wanted to add that this is obviously not the road I hope LO will take. I really appreciate all the time and work that goes into LO and wish I could contribute more to it than a couple of dollars each year and report a handful of bugs. My motivation for the harsh wording is aptly pointed out by a recent blog post of the design team: stability is the single most important aspect of (open) software. Frustrating software is worse than no software at all. (https://design.blog.documentfoundation.org/2017/09/13/open-source-means-libreoffice-users/)

Maybe there's even a way to monetarize LO for Mac to fund its development and get (back) to a truly stable and pleasant to use version? I think those "several thousands" of dollars could be a reachable goal if there is a clear and promising path towards a permanently stable software.

(Collabora Office and LibreOffice Vanilla on Mac App Store looked very promising to me but keep getting bad reviews as they were buggy from the start, aren't updated anymore and don't communicate their strategy. Probably focused on Collabora Online and Enterprise for understandable reasons.)
Comment 11 LenoreHorner 2017-09-21 21:16:35 UTC
I didn't actually notice slowness problems on MacOS (10.12.6) and LibreOffice 5.2.7.2 but when I upgraded to LibreOffice 5.3.6 I was definitely having problems scrolling.  I could scroll up or left (I think) in a document easily but right or down either was lagged or intermittent - in practice I had to scroll like I wanted to scroll a lot or I got nothing. At any rate, one direction on each axis was fine and the other was so bad I was having to click in a cell and arrow one row/column at a time in the desired direction.  I have two spreadsheets that sit open all day every day, one 40kB, one 32kB and both of them were behaving in the same unhelpful way.  I downgraded back to 5.2.7.2 because of this.
Comment 12 Alex 2017-09-26 19:02:05 UTC
I don't use Writer much so can't comment on that. But the general sentiment of the title definitely holds true for me. I have several spreadsheets which I use very often that just take annoyingly long to load on mac, but load very quickly on my Windows PC. The worst though is Impress, spreadsheets take forever to load and are just extremely cumbersome to work with, especially when there are any images or attachments of any kind. 

The whole suite just feels so sluggish on mac, yet it feels snappy and fine on Windows. Should be noted that there are many many reports of performance issues on Mac in the last few years. Just search google for "libreoffice slow mac" to find many examples.
Comment 13 Telesto 2017-09-26 19:43:42 UTC
The initial problem described in comment 0 should be fixed with 5.3.4. However I see quite a possibility the new slowness is caused by the issue combined in this metabug: bug 112486 (introduced with 5.3.2.2) Reading that 5.2.7.2 is OK but not 5.3.6.
Comment 14 Yannick.D 2017-09-28 15:02:17 UTC
Unfortunately, this bug isn't fixed. Confirmed with Version: 5.4.0.3, Build-ID: 7556cbc6811c9d992f4064ab9287069087d7f62c, Mac OS 10.12.6.

See video attached: Menus take 8-10s to show on a 2015 MacBook (Intel Core M-5Y51).

(In reply to Telesto from comment #13)
> The initial problem described in comment 0 should be fixed with 5.3.4.
> However I see quite a possibility the new slowness is caused by the issue
> combined in this metabug: bug 112486 (introduced with 5.3.2.2) Reading that
> 5.2.7.2 is OK but not 5.3.6.
Comment 15 Yannick.D 2017-09-28 15:04:30 UTC
Created attachment 136590 [details]
Issue not fixed in LO 5.4.0.3
Comment 16 William Gathoye 2017-10-15 16:38:36 UTC
Hello everyone. Coming from 5.3.x, I deployed 5.4.2 last week on a bunch of Macs and their users reported to me the problem somewhat faded away. Could you please check out with a more recent version than 5.4.0.3 and retry with a clean profile cf. https://wiki.documentfoundation.org/UserProfile#macOS ?
Comment 17 Yannick.D 2017-10-15 19:57:06 UTC
I did a very quick check with 5.4.2 and could not reproduce it right away. Definitely better! Still not perfectly fluid but may be back on par with 5.1.6. Thanks for the hint I will examine it further within the next week or so.
Comment 18 Raymond Wu Won 2017-10-15 21:35:15 UTC
There is an improvement with 5.4.2 here (macOS 10.13, 2016 13" no-touch bar MBP) and no aggravating spinner action, but it still feels like a delay (but not as long).

Importantly, there's no spinner after clicking on a "Create" item from the Startcentre so that does improve the feel too.

However, I'm going to keep 5.3.3.2 installed as well for now because of the down scrolling bug (Bug 109062) that affects all versions after that - I might have to weigh up slow/spinner dialog opening vs sluggish scroll-down behaviour.
Comment 19 Alex Thurgood 2017-10-16 10:07:30 UTC
Performance is still pretty slow, not only noticeable, but in the order of a second or two, especially when initiating dialog display :

- character dialog ;
- paragraph dialog ;
- numbering and bullets (particularly slow);
- page dialog.


Displaying or removing the sidebar doesn't seem to make any noticeable difference.

MacbookPro 15" i7 16Mb RAM

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
Threads CPU : 8; OS : Mac OS X 10.12.6; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 20 Alex Thurgood 2017-10-20 06:36:54 UTC
Tested on daily

Version: 6.0.0.0.alpha0+
Build ID: 0ad8447d3199e1c1d1f7d6ddabc9b4cded99c2d6
CPU threads: 4; OS: Mac OS X 10.13; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-10-19_07:06:36
Locale: fr-FR (fr_FR.UTF-8); Calc: group


The results are much the same. 

There is a noticeable improvement in speed compared to the previous situation, but it still takes approximately 2 seconds to display the :

Format > Paragraph
Format > Page
Format > Character
Format > Bullets & Numbering

dialogs in a blank Writer document, irrespectively of whether one uses the main menu or the context menu via right mouse button click.

It seems that constructing these dialogs is quite time intensive. From my own observations.

Most of the other dialogs or operations available from the main menu seem pretty snappy, apart from a very noticeable delay on first initialization of a Finder window, e.g. for saving, opening a file, inserting media, etc).
Comment 21 Alex Thurgood 2017-10-20 06:37:45 UTC
Certainly, on substantially equivalent hardware, the Mac version of LibreOffice is noticeably slower than its Linux counterpart.
Comment 22 Alex Thurgood 2017-10-20 15:28:44 UTC
Created attachment 137151 [details]
Time Profile from Apple Instruments

Time profile obtained from my symbols enabled build of master, opening a blank Writer document and right mouse button clicking and choosing Page to display the Page dialog.
Comment 23 Alex Thurgood 2017-10-20 15:46:14 UTC
Created attachment 137155 [details]
Complete Instruments Time Profile trace

Complete Instruments.trace produced by Apple Instruments
Comment 24 Jan-Marek Glogowski 2017-10-20 18:40:42 UTC
So for some reason in your profile, when calling Dialog::Execute, LO processes a delayed UserEvent generated by BackingWindow::dispatchURL called from somewhere earlier.

UserEvents have the highest priority in LO, and this adds a whooping 800ms to the 1.8s of opening the dialog. The dialog generation is actually just 600ms, so it's faster then in my debug build. I've never seen this in my traces - no idea, what's going on.
But generally opening the URL should probably be converted to an Idle, or it should run the scheduler for UI updates.
A single operation with 800ms on your HW is way too long and the priority of the file open operation is also way too high. Might be Ok, if there is no document yet open, so the user can't interact in any sensible way… well actually it's not.

Then there is the "first right click" delay, which initializes all macOS spelling and grammar checking engines for all languages, which currently is 280 for me. It's just once, but it takes 3.5s in my debug build. Changing this to an on-demand code, or a thread will be some work. I guess all other OS don't offer so many engines, or the initialization is cheaper. Never seen this either.
Comment 25 Ivan 2017-10-26 19:14:49 UTC
I confirm a similar bug (too slow) with draw.
Comment 26 Alex Thurgood 2017-10-27 08:23:07 UTC
(In reply to Jan-Marek Glogowski from comment #24)
> So for some reason in your profile, when calling Dialog::Execute, LO
> processes a delayed UserEvent generated by BackingWindow::dispatchURL called
> from somewhere earlier.
> 

The profile is the one created when instdir/LibreOffice.app is launched from the build tree, which means it is, in theory, "clean", so either this is symbols-build related or else there is something else going on that I don't know about...
Comment 27 Telesto 2017-11-14 19:42:28 UTC
(In reply to Alex Thurgood from comment #20)
> There is a noticeable improvement in speed compared to the previous
> situation, but it still takes approximately 2 seconds to display the :
> 
> Format > Paragraph
> Format > Page
> Format > Character
> Format > Bullets & Numbering 
 
> It seems that constructing these dialogs is quite time intensive. From my
> own observations.

Libo is opening all the dialog tabs in the 'background' to set the optimal dialog size (see https://opengrok.libreoffice.org/xref/core/vcl/source/control/tabctrl.cxx#2117)  Which can be a bit slow for tabs which need file access, for example color palettes (bug 112532).
Comment 28 Rene Meessen 2017-12-22 21:07:04 UTC
I have been using Draw on Win 11 and just switched to a new Macbook Pro 13".
Using 5.3.7.2 on the Mac

When I select an item and move the mouse nothing happens for two seconds then the item moves to the new position of the cursor.

It was a pleasure to work with on Win11 but its impossible to get any work done on the Mac.
Comment 29 Telesto 2017-12-22 21:33:07 UTC
(In reply to Rene Meessen from comment #28)
> I have been using Draw on Win 11 and just switched to a new Macbook Pro 13".
> Using 5.3.7.2 on the Mac
> 
> When I select an item and move the mouse nothing happens for two seconds
> then the item moves to the new position of the cursor.
> 
> It was a pleasure to work with on Win11 but its impossible to get any work
> done on the Mac.

Probably bug 105500. Something similar is happing in Impress (bug 106962). Disabling the sidebar should speed up things. Or using a LibreOffice version prior to LibO 5.1. 
https://downloadarchive.documentfoundation.org/libreoffice/old/

My personal preference is LibO 4.3.7.2
Comment 30 Cor Nouws 2017-12-23 12:07:45 UTC
(In reply to Rene Meessen from comment #28)
> I have been using Draw on Win 11 and just switched to a new Macbook Pro 13".
> Using 5.3.7.2 on the Mac


Thanks for reporting / testing.
Please don't change the version field (to a newer version): it shows the oldest version (known) with the bug.
Comment 31 Alex Thurgood 2018-03-05 13:39:44 UTC
So, I don't see any noticeable slowdown now with my master build of 01/03 or 02/03 (not sure which date exactly) :

Version: 6.1.0.0.alpha0+
Build ID: 9122f4598450d8a96e63fb29cc8166a6ae09587a
CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 32 Alex Thurgood 2018-03-05 13:40:37 UTC
Would affected users please try with a latest daily build and report back here ?
Comment 33 Telesto 2018-03-05 14:56:13 UTC
(In reply to Alex Thurgood from comment #32)
> Would affected users please try with a latest daily build and report back
> here ?

For the record: There are no daily builds available at the moment (since 8 february)
https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/
Comment 34 V Stuart Foote 2018-04-01 15:49:53 UTC
*** Bug 116730 has been marked as a duplicate of this bug. ***
Comment 36 Telesto 2018-04-04 20:08:05 UTC
Created attachment 141096 [details]
Bibisect log

Bisected to.. 

author	Caolán McNamara <caolanm@redhat.com>	2016-11-05 20:28:27 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2016-11-07 21:04:50 +0000
commit	64a708cba9b954afe3331f63c58218eb53b3d0ce (patch)
tree	ddc1bea3b63f32a1c6d377c1d1dd7aee0803fb70
parent	f01c49c4a89ecad2376fd0023625186e5cac642e (diff)
Revert "Reverts a commit series that cripple windows ci."
with addition of...

- svxlo-SvxColorListBox
+ svxcorelo-SvxColorListBox

This reverts commit db380aab1063e8a5e40111c40ee9f7921aa82601.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=64a708cba9b954afe3331f63c58218eb53b3d0ce

How
1. Right click a style and click modify -> monitor time taken

[Note: I might be mistaken however, it rather hard to differentiate]
Comment 37 Telesto 2018-04-04 20:13:48 UTC
Adding CC to Caolán McNamara
Comment 38 steve -_- 2018-05-10 10:31:16 UTC
Version: 6.0.4.2
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 4; OS: Mac OS X 10.13.4; UI render: default; 
Locale: de-DE (de_DE.UTF-8); Calc: group

not reproducible.

@Adomas, @Telesto: are you still seeing this problem using LO 6.0.4 on macOS 10.13.4?

master builds seem to be back, feel free to test that as well:
https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/

Setting to NEEDINFO, please set back to new after answering.
Comment 39 Adomas Venčkauskas 2018-05-11 10:38:52 UTC
I originally reported that this was taking well over 5 seconds. On the latest dev build this is taking a little under 5 seconds. I reported this over a year ago and have forgotten what the experience was then, but I see that other commenters noted that context-menus were taking a long time to open. Context-menus appear to open pretty instantaneously now. On the other hand, on my linux machine, the dialogs also come up pretty much instantaneously, so there is still room for improvement.
Comment 40 steve -_- 2018-05-12 09:20:42 UTC
Hm, I feel we should rather go with a new bug in that case. The video from 2017-02-23 shows the dialog takes 15+ seconds to open. If it is now under 5 that is quite an improvement. For me it is under 2 seconds.

@Adomas: Which macOS are you on? Are you using an SSD or HDD? How much RAM?
Comment 41 Adomas Venčkauskas 2018-05-12 09:28:08 UTC
I didn't realise I had attached a video when reporting. It has improved significantly compared to that video. I am still testing on the same 2014 MBP with 8GB RAM, 120GB SSD that I had tested with originally. The performance is still worse than Linux, but better than before.
Comment 42 Tor Lillqvist 2018-05-22 15:16:33 UTC
I looked into the time it takes for the Character... dialog to appear after selecting it in the right-click menu, and although not instantaneous, it didn't seem that overly slow to me (on my Retina iMac, but on the other hand a non-optimised debug build). Less than a second.

However, one thing I noticed while looking at the output produced with SAL_LOG=+TIMESTAMP+INFO.vcl+INFO.framework+INFO.sfx2 was the insane amount of things going on while the user is not doing anything in that dialog. Even if the focus is on a control that doesn't have any blinking caret, there is still some timer apparently firing every 20 ms. But yeah, this is just a FYI, I should file a separate bug for that.
Comment 43 Xisco Faulí 2018-05-28 10:03:16 UTC
> However, one thing I noticed while looking at the output produced with
> SAL_LOG=+TIMESTAMP+INFO.vcl+INFO.framework+INFO.sfx2 was the insane amount
> of things going on while the user is not doing anything in that dialog. Even
> if the focus is on a control that doesn't have any blinking caret, there is
> still some timer apparently firing every 20 ms. But yeah, this is just a
> FYI, I should file a separate bug for that.

Hi Tor,
Would you mind filling a new report with your finding so we can close this one as RESOLVED WORKSFORME as mentioned in comment 41 ?
Comment 44 Tor Lillqvist 2018-05-28 10:16:34 UTC
I already files a bug about that, bug #117744
Comment 45 Xisco Faulí 2018-05-28 10:54:19 UTC
(In reply to Tor Lillqvist from comment #44)
> I already files a bug about that, bug #117744

Thanks !!
Closing this one as RESOLVED WORKSFORME then...