Bug 130326 - XLSX: Long time for file opens and using 100% of one core of CPU after opening
Summary: XLSX: Long time for file opens and using 100% of one core of CPU after opening
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords: perf
Depends on:
Blocks: XLSX-Shapes Performance
  Show dependency treegraph
 
Reported: 2020-01-31 14:07 UTC by Roman Kuznetsov
Modified: 2022-11-13 12:58 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
XLSX file (1.29 MB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2020-01-31 14:09 UTC, Roman Kuznetsov
Details
perf flamegraph (160.85 KB, application/x-bzip)
2020-01-31 19:06 UTC, Julien Nabet
Details
Modified sample file without INDIRECT and ranges formula from 10000 to 50 (1.12 MB, application/zip)
2020-02-02 00:19 UTC, m_a_riosv
Details
Flamegraph (3.95 MB, image/svg+xml)
2021-04-09 09:37 UTC, Julien Nabet
Details
Flamegraph during scrolling (116.61 KB, application/x-bzip)
2021-04-09 09:46 UTC, Julien Nabet
Details
perf flamegraph during opening (330.52 KB, application/x-bzip)
2021-04-10 15:15 UTC, Julien Nabet
Details
perf flamegraph during opening (576.91 KB, application/x-bzip)
2021-04-12 07:14 UTC, Julien Nabet
Details
perf flamegraph during opening (311.44 KB, application/x-bzip)
2021-04-22 09:11 UTC, Julien Nabet
Details
Flamegraph (325.15 KB, application/x-bzip)
2021-04-30 08:24 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2020-01-31 14:07:56 UTC
Description:
XLSX: Long time for file opens and using 100% of one core of CPU after opening

Steps to Reproduce:
1. Open file from attach
2. It opens a long time
3. After opening it takes 100% of one core of CPU

I think there are problems with long formulas in D2:G38 range

Actual Results:
Long time for file opens and using 100% of one core of CPU after opening

Expected Results:
A file opens fast and doesn't use 100% of one core of CPU after opening


Reproducible: Always


User Profile Reset: No



Additional Info:
Версия: 7.0.0.0.alpha0+ (x64)
ID сборки: 47c598260a8f07cf3a1e4cab061df3f2d261932c
Потоков ЦП: 4; ОС:Windows 10.0 Build 17763; Отрисовка ИП: GL; VCL: win; 
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded
Comment 1 Roman Kuznetsov 2020-01-31 14:09:26 UTC
Created attachment 157561 [details]
XLSX file
Comment 2 Roman Kuznetsov 2020-01-31 14:27:04 UTC Comment hidden (obsolete)
Comment 3 Julien Nabet 2020-01-31 19:06:19 UTC Comment hidden (obsolete)
Comment 4 Julien Nabet 2020-01-31 19:07:27 UTC
After 20/30 secs waiting, I stopped the test (Ryzen 2600, 32Gb)
I'll give another try once this first pb will be fixed.
Comment 5 Roman Kuznetsov 2020-01-31 19:18:45 UTC Comment hidden (obsolete)
Comment 6 m_a_riosv 2020-02-02 00:19:01 UTC
Created attachment 157586 [details]
Modified sample file without INDIRECT and ranges formula from 10000 to 50

Modifying the sample file without INDIRECT function and ranges in formula from 10000 to 50, the issue still persist. After open I'm not able to do anything on it.
Comment 7 Xisco Faulí 2021-04-08 19:23:31 UTC
it takes

real	1m19,083s
user	1m15,514s
sys	0m2,075s


in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 78eaf6489a6542378ffab7eef39ec0a2c5f1a10a
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 8 Xisco Faulí 2021-04-08 19:56:29 UTC
Import time went down to 1 minute 20 seconds after

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

author	Noel Grandin <noel.grandin@collabora.co.uk>	2020-03-03 09:23:30 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2020-03-10 09:26:19 +0100
commit edf13fe1247e7ef411a9ff5435385573fad01f56 (patch)
tree a0f03fa1b87b8cb5e14b5113754d53322c1c78b8
parent 6db846c3c0bc1c44da1f3c7a8dea385930acc3b1 (diff)
tdf#93831 xlsx file full of pictures of numbers slow to open

@Roman, is the import time acceptable for you now ?
Comment 9 Roman Kuznetsov 2021-04-08 20:11:03 UTC
(In reply to Xisco Faulí from comment #8)

> 
> @Roman, is the import time acceptable for you now ?

it's better than before the patch, but Excel opens it for 5 sec only. In LO it looks as LO hangs instead opening.

Funny, LO and Excel take 100% of one CPU core when you try scroll the sheet.
Comment 10 Julien Nabet 2021-04-09 09:37:54 UTC
Created attachment 171057 [details]
Flamegraph

Here's a new Flamegraph of the file opening on pc Debian x86-64 with master sources updated today (without enable-dbgutil) by using gen rendering (to avoid accessibility stuff with gtk3).
Comment 11 Julien Nabet 2021-04-09 09:46:59 UTC
Created attachment 171058 [details]
Flamegraph during scrolling
Comment 12 Commit Notification 2021-04-09 13:10:18 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/79ef2cef85f35aeb11b620fdc82acd595a7cb4fb

tdf#130326 related, speed up scrolling

It will be available in 7.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 13 Commit Notification 2021-04-10 13:35:08 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/526f0fce45fb014b09057403ae37c125e5a18655

tdf#130326 speed up opening XLSX

It will be available in 7.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 14 Commit Notification 2021-04-10 14:53:48 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/566e43d2129dd6c70bb718296ce66353e7ff824b

tdf#130326 speed up XLSX load

It will be available in 7.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 15 Commit Notification 2021-04-10 14:54:59 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/44711d9eb53eb6247ebdb9293a3eb5e643f78059

tdf#130326 related, speed up drawing

It will be available in 7.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 16 Julien Nabet 2021-04-10 15:15:16 UTC
Created attachment 171084 [details]
perf flamegraph during opening

Here's a new Flamegraph with master sources updated today (526f0fce45fb014b09057403ae37c125e5a18655)
Comment 17 Noel Grandin 2021-04-11 11:15:23 UTC
Why does this document appear to contain a ton of drawings? Where are they?
Comment 18 m_a_riosv 2021-04-11 11:41:09 UTC
Navigator shows 19562 text boxes.
Comment 19 Commit Notification 2021-04-12 06:28:06 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f9fae84cbd9663d6a394aa8e4e4b927c11384815

tdf#130326 speed up XLSX load in ScFlatSegmentsImpl

It will be available in 7.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 20 Julien Nabet 2021-04-12 07:14:30 UTC
Created attachment 171110 [details]
perf flamegraph during opening

Here's a new Flamegraph with master sources updated today (ac87ae4615fc96c247ca98a321c69400411dab06)
Comment 21 Julien Nabet 2021-04-12 07:15:58 UTC
Sorry, I forgot to change env var, last one is with gtk3 rendering not with gen rendering :-(
Comment 22 Roman Kuznetsov 2021-04-12 08:07:41 UTC
It takes 57 sec for file opening and still takes about 50% of one CPU core while scrolling in build from 12 April 2021

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 7a0e0a84a02f505200331c19b28d45e898cd5a12
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded
Comment 23 Commit Notification 2021-04-12 10:32:16 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/40f9888ddc5def405d5a7724cb70f26eca527f01

tdf#130326 flatten SfxItemPropertyMap

It will be available in 7.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 24 Xisco Faulí 2021-04-12 12:14:31 UTC
it takes

real	0m34,414s
user	0m32,675s
sys	0m1,670s

in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 4eac7a11e5d39ca6c783f65f1ca2df009b9a37e4
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Nice improvement!!!

@Roman, you branch from comment 22 is missing two commits improving this issue...
Comment 25 Commit Notification 2021-04-13 12:04:32 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f6d1da91ccda960d1ee738d688a2cb374e576aef

tdf#130326 no need to fill ScMatrix with zeros here

It will be available in 7.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 26 Commit Notification 2021-04-13 14:01:00 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/64152322b99556b2e80a58cdf04a586e6941ba10

tdf#130326 speed up row height calculated

It will be available in 7.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 27 Roman Kuznetsov 2021-04-14 19:22:06 UTC
(In reply to Xisco Faulí from comment #24)
> it takes
> 
> real	0m34,414s
> user	0m32,675s
> sys	0m1,670s
> 
> in
> 
> Version: 7.2.0.0.alpha0+ / LibreOffice Community
> Build ID: 4eac7a11e5d39ca6c783f65f1ca2df009b9a37e4
> CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded
> 
> Nice improvement!!!
> 
> @Roman, you branch from comment 22 is missing two commits improving this
> issue...

OK, 43 sec, in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

I think CPU is matter here (Intel Core 2 Quad Q9450, 4 CPU core with 2.66GHz)
Comment 28 Noel Grandin 2021-04-22 07:45:55 UTC
So I had this improved down to around 17s, but since the ScNavigatorDlg/ScContentTree welding, it is back to around 24s on my machine,

Caolan, perhaps you have some ideas about reducing how often the navigator updates?

(The navigator also rebuilds the tree every time the cursor changes cells, which makes clicking around the lower parts of this spreadsheet - around row 1000 - very very slow)
Comment 29 Julien Nabet 2021-04-22 09:11:19 UTC
Created attachment 171350 [details]
perf flamegraph during opening

Here's an updated Flamegraph with master sources updated today (1b1a9c6c12ebe4cac19e34ff5e4818998bbb2537) + gen rendering.
Comment 30 Commit Notification 2021-04-23 09:05:16 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/91385bbc7cccfdf59f60a24eaf81894772134af0

tdf#130326 related, speed up drawing

It will be available in 7.1.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 31 Commit Notification 2021-04-23 11:41:47 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/7d0e88ce674a7e809352842bcce3cd67f548a524

Revert "tdf#130326 related, speed up drawing"

It will be available in 7.1.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 32 Caolán McNamara 2021-04-23 13:37:40 UTC
(In reply to Noel Grandin from comment #28)
> So I had this improved down to around 17s, but since the
> ScNavigatorDlg/ScContentTree welding, it is back to around 24s on my machine,
> 
> Caolan, perhaps you have some ideas about reducing how often the navigator
> updates?

Maybe instead of immediately updating just schedule an idle to do the update. So at least there isn't multiple updates during load and instead just one at the end ?
Comment 33 Jean-Baptiste Faure 2021-04-23 14:45:58 UTC
(In reply to m.a.riosv from comment #18)
> Navigator shows 19562 text boxes.

Yes, 19562 text boxes 0 cm wide. It's very difficult to open their contextual menu. It's a use case where we see that the possibility to edit these objects from the Navigator is missing. If you succeed to open the contextual menu you can change the size and the background of the object to make it visible.

This file make me thinking to files produced by Crystal Report in RTF format where each cell is made with 4 small line objects. There is several bug reports related to such files.

Perhaps LO should remove an 2D object if its area is null.

Best regards. JBF
Comment 34 Commit Notification 2021-04-23 18:53:27 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1333600682019891efdb4acf51c4c1a9b7d3532d

tdf#130326 clamp number of items in calc content tree

It will be available in 7.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 35 Noel Grandin 2021-04-23 18:56:06 UTC
I have done what I can here, I'm not going to work on this any more
Comment 36 Roman Kuznetsov 2021-04-24 08:16:37 UTC
(In reply to Jean-Baptiste Faure from comment #33)
> (In reply to m.a.riosv from comment #18)
> > Navigator shows 19562 text boxes.
> 
> ....
> Perhaps LO should remove an 2D object if its area is null.
> 
> Best regards. JBF

Of course NO. If LO opens 2D objects with wrong sizes it means we just should fix it but not delete those objects.
Comment 37 Julien Nabet 2021-04-24 08:35:20 UTC
(In reply to Roman Kuznetsov from comment #36)
> ...
> Of course NO. If LO opens 2D objects with wrong sizes it means we just
> should fix it but not delete those objects.

Do you mean Excel shows indeed 19562 text boxes with the initial xlsx file? If yes, could you provide a screenshot?
If they don't appear in the screenshot, I think Jean-Baptiste is right and we should delete these nonsense text boxes.
Comment 38 Commit Notification 2021-04-24 18:19:29 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ff8addee9c2c43c6ec064395e909665932e10899

Related: tdf#130326: GetDrawNames doesn't do anything when !bisInNavigatoeDlg

It will be available in 7.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 39 Caolán McNamara 2021-04-24 20:04:10 UTC
Those constant refreshes on each click in a cell are since:

commit b41332475783c31136673fb44cf4c411bb0148f8
Author: Steve Yin <steve_y@apache.org>
Date:   Mon Dec 2 15:54:29 2013 +0000

    Integrate branch of IAccessible2

in sc/source/ui/navipi/navipi.cxx with

+ case FID_KILLEDITVIEW:
+     aLbEntries.ObjectFresh( SC_CONTENT_OLEOBJECT );
+     aLbEntries.ObjectFresh( SC_CONTENT_DRAWING );
+     aLbEntries.ObjectFresh( SC_CONTENT_GRAPHIC );
+     break;

even though we already have a handler of

 case SfxHintId::ScDrawChanged:
     m_xLbEntries->Refresh( ScContentId::GRAPHIC );
     m_xLbEntries->Refresh( ScContentId::OLEOBJECT );
     m_xLbEntries->Refresh( ScContentId::DRAWING );
     break;

and those "Refresh" as opposed to "ObjectFresh" try not to clear and refill the navigator unless content has changed.

and that ObjectFresh seems to really center on the use of "sKeyString" which is only set by ScContentTree::KeyInputHdl (in that same commit) if space is used to select an entry with the comment "Make KEY_SPACE has same function as DoubleClick".

I suspect ObjectFresh is a cut and paste job from Refresh that just wants to keep the same item selected (and expanded) in the navigator that was selected by the user before any content change that might cause the navigator to refill
Comment 40 Commit Notification 2021-04-25 14:42:21 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/59ec383c75837b017cd593adb2a85fba9b2970c5

Related: tdf#130326: GetDrawNames doesn't do anything when !bisInNavigatoeDlg

It will be available in 7.1.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 41 Roman Kuznetsov 2021-04-26 16:50:12 UTC
May be I missed something?

It takes 1 min 20 sec in today's daily build

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 15a9bee9ef26ce13ed1e26319306a88b6d886158
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded
Comment 42 Commit Notification 2021-04-27 07:50:03 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1a891f2fadae01aca95157b09d6ea8e223bee1ea

Related: tdf#130326 allow bulk_insert_for_each to insert under a node

It will be available in 7.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 43 Commit Notification 2021-04-27 07:52:19 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c0cbd13c945c5f47057b413efc88b2e3bb72d025

Related: tdf#130326 drop ScContentTree::ObjectFresh

It will be available in 7.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 44 Roman Kuznetsov 2021-04-27 08:47:29 UTC
(In reply to Julien Nabet from comment #37)
> (In reply to Roman Kuznetsov from comment #36)
> > ...
> > Of course NO. If LO opens 2D objects with wrong sizes it means we just
> > should fix it but not delete those objects.
> 
> Do you mean Excel shows indeed 19562 text boxes with the initial xlsx file?
> If yes, could you provide a screenshot?
> If they don't appear in the screenshot, I think Jean-Baptiste is right and
> we should delete these nonsense text boxes.

I mean it doesn't matter Excel shows or not those objects. There are they there and we must import it as is.
Another question if we import it wrong. Then we should fix it
Comment 45 Julien Nabet 2021-04-27 09:05:39 UTC
(In reply to Roman Kuznetsov from comment #44)
> (...
> 
> I mean it doesn't matter Excel shows or not those objects. There are they
> there and we must import it as is.
> Another question if we import it wrong. Then we should fix it

In comment 9, you talked about Excel which took 9sec to open the file so yes it matters if Excel shows them or not. If it doesn't show them perhaps it doesn't take these 19562 text boxes into account and it's indeed easier to open more quickly.
Comment 46 Commit Notification 2021-04-28 18:34:20 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/99668e79c13fee09f8d776dbcd28e7667d7f68fe

Related: tdf#130326 skip calling Refresh if its already just called

It will be available in 7.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 47 Commit Notification 2021-04-29 12:33:03 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/f275e019199baa931f1e4681e1bf29d68aae7a32

Related: tdf#130326 drop ScContentTree::ObjectFresh

It will be available in 7.1.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 48 Commit Notification 2021-04-29 12:57:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/5f5cf0d66d14ff246a4fce681459eb605d6c5f39

Related: tdf#130326 skip calling Refresh if its already just called

It will be available in 7.1.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 49 Julien Nabet 2021-04-30 08:24:12 UTC
Created attachment 171520 [details]
Flamegraph

I don't know if there's still something we can improve here but here's an updated Flamegraph concerning file opening with master sources updated today + gen rendering.
Comment 50 Roman Kuznetsov 2021-05-01 08:27:13 UTC
34 sec for opening in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: a52590d76b89dc75be2aa87f4287624c89f1e82f
CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: threaded

and it's still has a delay when I try scrolling the sheet
Comment 51 Julien Nabet 2021-05-01 08:38:19 UTC Comment hidden (obsolete)
Comment 52 Julien Nabet 2021-05-01 08:41:28 UTC Comment hidden (obsolete)
Comment 53 Roman Kuznetsov 2022-04-09 21:15:50 UTC
(In reply to Roman Kuznetsov from comment #27)

> OK, 43 sec, in
> 
> Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
> Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad
> CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render:
> Skia/Raster; VCL: win
> Locale: ru-RU (ru_RU); UI: ru-RU
> Calc: CL
> 
> I think CPU is matter here (Intel Core 2 Quad Q9450, 4 CPU core with 2.66GHz)

Still the same time with the same CPU in

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: ccb78b98e0618cce365562fe326d018892b8104a
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL Jumbo