Confirming with

Version: 6.2.0.0.alpha0+
Build ID: 030181b37d2b7edd7cab20ceb7736e575186f99b
CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: threaded


As things go, the performance of this set of steps is pretty bad. The user gets the impression that LO is not responding.

Compared with 

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

where scrolling through a large document after/before spellcheck is not brilliant, but still a hundred times more responsive than current master.

Not much to complain with
Version: 4.3.7.2
Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba

I had a look at this with Instruments.app, the Apple provided developer tool and carried out a time profile using an older version of the Writer Guide ODT as a test document in a non-debug, production release version of LO 6152.

A fairly significant amount of time, when scrolling either with the vertical document scrollbar or the mouse wheel scroll function, comes from :

+0x160	callq               "PaintHelper::DoPaint(vcl::Region const*)"

which is called several hundred times in certain cases, leading to a time occupation of several hundred milliseconds.

That call is linked to :


vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags)

which calls

SwDashedLine::Paint(OutputDevice&, tools::Rectangle const&)

I am enclosing a screenshot of the Instruments.app output zoomed in on an area of the trace where the processing time caused a noticeable slowdown/lag in cursor scrolling.

Analysing the functions called in this area of the trace points to the calls I indicated above.

Created attachment 151021 [details]
Screenshot of Time Profile Analysis using Apple Instruments

After running through the bisect, I think the issue may be that the earlier version actually didn't do the spellchecking.  There was no squiggly lines in the earlier version.  So it had no lagging.  

Once the actual spellchecker works properly in the later version, it takes a longer period to go through the 350,000 words to check.  So while it's checking, it's laggy.  It takes some time to load the document into memory???

In any case, after bisecting, it looks like this is the point where the laggyness starts. 

``` 1603750e58289a61a295a01dd3d105b2325506f7 is the first bad commit
commit 1603750e58289a61a295a01dd3d105b2325506f7
Author: gerrit <gerrit@gerrits-Mini.home>
Date:   Thu Jul 12 00:32:02 2018 +0200

    source 0fb5ca6cc9cc55a4436a36c533461769b1fc8526
    
    source 0fb5ca6cc9cc55a4436a36c533461769b1fc8526

 .../Contents/Frameworks/libwriterfilterlo.dylib    | Bin 3197776 -> 3161088 bytes
 LibreOffice.app/Contents/Resources/setuprc         |   2 +-
 LibreOffice.app/Contents/Resources/versionrc       |   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
```

(In reply to bunkem from comment #6)
> After running through the bisect, I think the issue may be that the earlier
> version actually didn't do the spellchecking.  There was no squiggly lines
> in the earlier version.  So it had no lagging.  
> 
> Once the actual spellchecker works properly in the later version, it takes a
> longer period to go through the 350,000 words to check.  So while it's
> checking, it's laggy.  It takes some time to load the document into memory???
> 
> In any case, after bisecting, it looks like this is the point where the
> laggyness starts. 
> 
> ``` 1603750e58289a61a295a01dd3d105b2325506f7 is the first bad commit
> commit 1603750e58289a61a295a01dd3d105b2325506f7
> Author: gerrit <gerrit@gerrits-Mini.home>
> Date:   Thu Jul 12 00:32:02 2018 +0200
> 
>     source 0fb5ca6cc9cc55a4436a36c533461769b1fc8526
>     
>     source 0fb5ca6cc9cc55a4436a36c533461769b1fc8526
> 
>  .../Contents/Frameworks/libwriterfilterlo.dylib    | Bin 3197776 -> 3161088
> bytes
>  LibreOffice.app/Contents/Resources/setuprc         |   2 +-
>  LibreOffice.app/Contents/Resources/versionrc       |   2 +-
>  3 files changed, 2 insertions(+), 2 deletions(-)
> ```

Telesto: can you take a look at this as well? Apparently this was bibisected with the 6.0 repo.

I tried the 7.5 release on MacOS and it has the same beachball and lagging. It also shows the squiggly line under the English text.
 
Also tried Windows 10 version of 7.3.1.3.  There is no lagging or beachball once I turned on the Auto Spellchecker.  However I see that there aren't any squiggly lines under the text.

This makes me think that the there is something in the document language settings that is functioning strangely on the Mac.  The Mac appears to think there are English spelling mistakes in the text that is English in the sample document.  The document says something about Dutch Netherlands in the language at the bottom of the main window but all the text is English.  So while the document text may be Dutch, the words shouldn't show spelling mistakes when my default language is English and the text is in English and the spellcheck is English.

The Windows v7.3.1.3 reads the text correctly and doesn't show spelling mistakes as there are none.  This is correct.

I can still reproduce this in LODev Version: 

7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 4ca4282517d02592966576fc642048b3d5ae5532
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

from a daily aarch64 build tb84 buildbot from 25/03/2023

The lag only occurs initially, and lasts maybe about a minute or two during which constant scrolling through the document jumps in fits and starts, then all of a sudden becomes smoother and follows actual mouse/scroll movement.

Presumably, this has something to do with the automatic spellcheck which is active when the file is loaded.