Description: 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: 7.3.0.0.alpha0+ (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
Created attachment 174721 [details] Example file
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. https://cgit.freedesktop.org/libreoffice/core/commit/?id=e0e21f2747c19dae13332f4e59949c717aa114f3
Comment 0 about 6.1 being wrong.. started with 6.2
@David, 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)
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
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.
So multi-threaded calculation is a culprit, adding meta.
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...
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
Just tested on Ubuntu 18.04.6 with LO 7.3.0.2 and it took 2.5 seconds. Wondering if the fix for Bug 144249 helped here too. Marking as WFM but please do double-check.
stragu, thanks for checking, but please test always with trouble version and fresh or beter master to compare on the same system.
I have 1 sec or less delay on Linux and Windows, but this is also with 7.2.5.
Well for me is selected cell A8 & pressing delete still slow (selecting row a8 & delete being fast) Version: 7.4.0.0.alpha0+ (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
(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 realised the two seconds I mentioned was until the scrolling _started_ to respond, but it was still stuttering or stopping for a few more seconds afterwards. Time before I can scroll without stuttering is actually pretty similar between versions: In 7.2.5: about 6 seconds in 7.3.0.2: about 6 seconds In 7.4 alpha0+: about 7 seconds There is a clear delay between when the cell values are updated (emptied or result of formula changed) and when the scrolling is smooth. Version: 7.4.0.0.alpha0+ / 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.
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 7.3.0.2: about 3 seconds In 7.4 alpha0+: about 3 seconds Undoing the operation seems to take a similar time. Version: 7.4.0.0.alpha0+ / 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.
Sorry, I was deleting row, not cell.
(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 7.4+ 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?
*** This bug has been marked as a duplicate of bug 144777 ***
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.