Bug 144257 - Recalculating after deleting cell contents (used in formulas) increased from 2 to 10 seconds if multi-threaded
Summary: Recalculating after deleting cell contents (used in formulas) increased from ...
Status: RESOLVED DUPLICATE of bug 144777
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, perf
Depends on:
Blocks: Calc-Threaded
  Show dependency treegraph
Reported: 2021-09-02 06:44 UTC by Telesto
Modified: 2022-05-12 10:33 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:

Example file (351.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-09-02 06:45 UTC, Telesto
Bibisect log (3.20 KB, text/plain)
2021-09-02 07:12 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-09-02 06:44:58 UTC
Recalculating after deleting cell content increased from 2 seconds (6.0) to 10 seconds with (7.3)

Steps to Reproduce:
1. Open the attached file (have process monitor tool at your hand
2. Click A8 and press delete -> count the time needed to finish

Actual Results:
10 seconds with 7.3
8 seconds with 6.1
2 seconds with 6.0

Expected Results:
2 seconds sounds nice :-)

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64) / LibreOffice Community
Build ID: 05ff3d67d0e2e436406786c949eb7cfca107ba33
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2021-09-02 06:45:31 UTC
Created attachment 174721 [details]
Example file
Comment 2 Telesto 2021-09-02 07:12:26 UTC
Created attachment 174722 [details]
Bibisect log

Bisected to:
author	Luboš Luňák <l.lunak@collabora.com>	2018-06-15 18:22:12 +0200
committer	Luboš Luňák <l.lunak@collabora.com>	2018-06-15 21:53:55 +0200
commit e0e21f2747c19dae13332f4e59949c717aa114f3 (patch)
tree 0bd7e29e6aef9b563a2bce4053c2918101e5c519
parent f07cc44b5ad3230e01f1f2d16fd074867bddc449 (diff)
clean up calc'c choosing between threading and OpenCL
Now there's just one place to decide what is used first,
in InterpretFormulaGroup(). Place in other places now checks both threading
and OpenCL, which should be cheap, but it also allows e.g. falling
back from OpenCL to threading if it doesn't work out for a specific
formula group.

Comment 3 Telesto 2021-09-02 07:13:15 UTC
Comment 0 about 6.1 being wrong.. started with 6.2
Comment 4 Telesto 2021-09-02 20:04:44 UTC
FYI: I recycled a part of you're spreadsheet at bug 144205. The file opening here is slowish because of bug 124098. And recalculating after deleting cell content is slow because of the commit at comment 2. It's possible that both are entangled (so slow recalculation & row height madness. At least that's how I read: bug 124098 comment 39. And there is also bug 144250 (which also appears to be connected to the row height recalculation; it's likely a twist in the expression of the same flaw)
Comment 5 Timur 2021-09-03 12:36:51 UTC
Test Linux bibisect repos. I confirm the bug but not the bibisect result. 
Bug should be in 6.1. Before and after commit of Comment 2 is similar, slow. 
Maybe repos are not OK. 

6.0 master:          2 sec
6.1 oldest:        100+, frozen
6.1 master:         12 sec
6.2 before commit:  12 sec
7.3+                 8 sec
Comment 6 Timur 2021-09-03 12:59:26 UTC
Bibisect in 6.1:
commit 38bd1dd9533307ca905cdf14b0842aacce61e7e1
Date:   Sat May 26 03:13:32 2018 +0200
    source 1360a86cc3ccbe228acf2428a5e230cdf030bfde
    pre 14257916b872103b0c8e998499d3e30c94c7b9bb

author	Michael Meeks <michael.meeks@collabora.com>	2018-05-24
Re-enable threading for formula groups for now.
As agreed at the ESC - lets see how this goes for 6.1
This reverts commit 4696d3728f0aba1087001bc543fc0867dd0ebdda.

commit 4696d3728f0aba1087001bc543fc0867dd0ebdda	[log]
author	Michael Meeks <michael.meeks@collabora.com>	Wed Jan 31 2018 
Disable threading for formula groups for now.
Comment 7 Timur 2021-09-03 13:09:56 UTC
So multi-threaded calculation is a culprit, adding meta.
Comment 8 Telesto 2021-09-03 13:53:54 UTC
Would someone mind to verify my Windows bibisect result, please. There might well be a difference between Windows & Linux...

I find it pretty particular that both bibisects point (Linux/Win) both point to "FormulaGroups" code, only different code..  

Also the 'bug' at bug 144250 points to yet again the FormulaGroups code, but again different commit. 

It's my impression that for somehow a recalculation is trigger followed (or together with) a by row height recalculation. But well I could be totally wrong...
Comment 9 Telesto 2021-09-03 13:55:48 UTC
Adding CC: to Michael Meeks (based on comment 6)
Adding CC: to Luboš Luňák  (based on comment 2) & his work on the FormulaGroup code
Comment 10 Stéphane Guillou (stragu) 2022-01-23 12:38:35 UTC
Just tested on Ubuntu 18.04.6 with LO and it took 2.5 seconds.
Wondering if the fix for Bug 144249 helped here too.

Marking as WFM but please do double-check.
Comment 11 Timur 2022-01-23 14:16:14 UTC
stragu, thanks for checking, but please test always with trouble version and fresh or beter master to compare on the same system.
Comment 12 Buovjaga 2022-01-23 16:38:50 UTC Comment hidden (obsolete)
Comment 13 Telesto 2022-01-23 20:47:13 UTC
Well for me is selected cell A8 & pressing delete still slow (selecting row a8 & delete being fast)
Version: (x64) / LibreOffice Community
Build ID: 4a388f5e01ebb5a512931d11e48c4380382239c8
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 14 Stéphane Guillou (stragu) 2022-01-24 04:10:44 UTC Comment hidden (obsolete)
Comment 15 Stéphane Guillou (stragu) 2022-01-24 04:17:48 UTC
ugh, sorry about the previous comment, I was confusing this report with the scrolling one: Bug 144250

Here it is again, focusing on the issue reported here:

(In reply to Timur from comment #11)
> stragu, thanks for checking, but please test always with trouble version and
> fresh or beter master to compare on the same system.

What do you mean by "trouble version"? The earliest version affected according to this bug report is 6.2, which is an unmaintained branch, and the most recent version tested by Telesto in Comment 0 was 7.3, which is the one I picked to test (a currently maintained branch). I think my WFM was a justified call, but I said I'd like someone else to check and I'm happy to do more testing.

I tested a number of times to have a better idea of how much time it takes before the values are updated:

In 7.2.5: about 3 seconds
in about 3 seconds
In 7.4 alpha0+: about 3 seconds

Undoing the operation seems to take a similar time.

Version: / LibreOffice Community
Build ID: 571438a34ad9aba0d496a89e8345851331740fbd
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Setting back to NEW.
Comment 16 Buovjaga 2022-01-24 08:40:40 UTC
Sorry, I was deleting row, not cell.
Comment 17 Timur 2022-01-24 15:04:16 UTC
(In reply to Timur from comment #5)
> 6.0 master:          2 sec
> 6.1 oldest:        100+, frozen
> 6.1 master:         12 sec
> 6.2 before commit:  12 sec
> 7.3+                 8 sec

We have different systems, but versions with change were identified. 
So now are relevant for test: 6.0 master/latest to see how fast it was, 7.3 oldest to see how it was when reported, master which is 7.4+ to see it now.

7.4+ seem unchanged from 7.3-, faster than 6.2 but slower than without multi-threaded calc, which is almost instant. 
So key question remains: why is multi-threaded calc slower?
Comment 18 Luboš Luňák 2022-05-11 10:00:56 UTC

*** This bug has been marked as a duplicate of bug 144777 ***
Comment 19 Timur 2022-05-12 10:33:24 UTC
It's 4 secs for me now in 7.4+ with multi-threaded calc. 
Not as good as without it (why?) but better than before.