Created attachment 131430 [details]
A video showing the issue

This happens on a 2014 MacBook Pro with plenty of resources to respond fast.

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)

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.

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.

Created attachment 132593 [details]
IRC logs describing the problem

There is slowness on all platforms when opening cell formatting dialog in Calc: bug 98132

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

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/.

(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?

(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.)

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.

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.

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.

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.

Created attachment 136590 [details]
Issue not fixed in LO 5.4.0.3

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 ?

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.

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.

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

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).

Certainly, on substantially equivalent hardware, the Mac version of LibreOffice is noticeably slower than its Linux counterpart.

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.

Created attachment 137155 [details]
Complete Instruments Time Profile trace

Complete Instruments.trace produced by Apple Instruments

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.

I confirm a similar bug (too slow) with draw.

(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...

(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).

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.

(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

(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.

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

Would affected users please try with a latest daily build and report back here ?

(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/

*** Bug 116730 has been marked as a duplicate of this bug. ***

Maybe related: https://ask.libreoffice.org/en/question/150823/extremely-slow-stylemodel-configuration-window/

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]

Adding CC to Caolán McNamara

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.

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.

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?

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.

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.

> 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 ?

I already files a bug about that, bug #117744

(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...