Bug 144205 - Calc: Delete Column and further Insert and Delete never instant but considerably slower from LO 7.2 (12 seconds)
Summary: Calc: Delete Column and further Insert and Delete never instant but considera...
Status: RESOLVED DUPLICATE of bug 144777
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, perf, regression
Depends on:
Blocks:
 
Reported: 2021-08-31 07:54 UTC by David Lynch
Modified: 2022-05-03 14:49 UTC (History)
6 users (show)

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


Attachments
See comment 2 (700.16 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-08-31 15:11 UTC, David Lynch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Lynch 2021-08-31 07:54:09 UTC Comment hidden (obsolete)
Comment 1 Timur 2021-08-31 12:23:10 UTC Comment hidden (obsolete)
Comment 2 David Lynch 2021-08-31 15:11:38 UTC
Created attachment 174675 [details]
See comment 2

See comment 2
Comment 3 David Lynch 2021-08-31 15:13:48 UTC
Sorry, my initial report was wrong. There appears to be no significant difference in performance between 7.1.4 and 7.1.5. The issue is that some commands are sometimes instantaneous and sometimes take about 6 seconds.
I attach file bug1.
Select on column AU ->[Insert Columns Before] instantaneous.
Delete new column AU instantaneous
Select BH2:BH3[Fill Down]
Again select column AU ->[Insert Columns Before] 6 seconds.
Again delete new column AU 6 seconds

There appear to be two modes, one instantaneous. One in which commands take 6 seconds and "Adapt Row Height" appears in the Status Bar. The rows are set to a fixed height of .5cm.

The following induce slow mode:
insert column
delete column
entering data in a cell
entering a formula in a cell
fill down

The following induces fast mode:
show row (even if no rows are hidden)
Comment 4 QA Administrators 2021-09-01 04:19:14 UTC Comment hidden (obsolete)
Comment 5 Timur 2021-09-01 10:44:02 UTC
> Select on column AU ->[Insert Columns Before] instantaneous.
6s in LO 6.1, 0s in 6.2, 0s in 7.1, 0s in 7.2&7.3+

> Delete new column AU instantaneous
6s in LO 6.1, 3s in LO 6.2, 3s in LO 7.1, 6s in Lin and 12s in Win LO 7.2&7.3+

> Select BH2:BH3[Fill Down]
Can be tested also without this. 

> Again select column AU ->[Insert Columns Before] 
6s in LO 6.1, 3s in LO 6.2, 3s in LO 7.1, 6s in Lin and 12s in Win in LO 7.2&7.3+

> Again delete new column AU 6 seconds
6s in LO 6.1, 3s in 6.2, 3s in LO 7.1, 6s in Lin and 12s in Win in LO 7.2&7.3+

> There appear to be two modes, one instantaneous. One in which commands take
> 6 seconds and "Adapt Row Height" appears in the Status Bar. 
Yes. 
In 6.2 was a change in bug 62268, that seems like an improvement.
In 7.2 there was a regression, let's assume it's bug 144155.
Here: 0s is instant, 3s is slow, 6s is more slow, 12s is even more slow. 
 
> The following induce slow mode:
> insert column
> delete column
> entering data in a cell
> entering a formula in a cell
> fill down

Sample is very good and I reproduce this. But I'm not sure if this should be confirmed because there's bug 144155 and bug 124098.
Comment 6 Xisco Faulí 2021-09-07 08:20:59 UTC Comment hidden (obsolete)
Comment 7 David Lynch 2021-09-07 11:10:30 UTC
The performance issues still appear:

Open file bug1.
Select on column AU ->[Insert Columns Before] instantaneous. >>> still instantaneous.
Delete new column AU instantaneous >>> now 13 sec
Select BH2:BH3[Fill Down] >>> now 23 sec
Again select column AU ->[Insert Columns Before] 6 seconds. >>> now 11 sec
Again delete new column AU 6 seconds >>> now 11 sec 
>>>>
selecting a column >>> now 6 secs
deleting data in a cell >>> now 10 secs
deleting a formula (=AO10) in a cell >>> now 10 secs. 

This is the first time I've installed a daily build, have I got the correct one:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: c7b5e6566d9b24a0a996c739a945004d9aadee2f
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded
Comment 8 David Lynch 2021-09-10 10:00:02 UTC
There are still performance issues with the latest revision (see bug 144155). The following tests are on attachment 174675 [details]:

Hide row > instantaneous
Show row > instantaneous
Select cell > instantaneous
Enter data in cell > instantaneous
Enter simple formula (=AO1) in cell > instantaneous
Insert column > 10 secs
Fill down BH2:BH3 > 11 secs
Delete data from (a single) cell > 20 secs
Delete simple formula (=AO1) in cell > 10 secs
Select row > 10 secs


Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 96d1240adf946c443fb2c369a1c84e31e259c7a8
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded
Comment 9 Telesto 2021-09-13 12:15:11 UTC Comment hidden (obsolete)
Comment 10 Colin 2021-09-15 09:43:29 UTC
I have further information which appears to be related to the "overall picture" but is directly referencing and comparing performance for "Hide" and "Group and Outline".
This bug was identified within "Ask Libre" as pertinent to my enquiry

Version: 7.2.0.4 (x64) / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: sv-SE (en_GB); UI: en-GB
Calc: threaded
i5 @3.4Ghz 8GB RAM

If I open LoCALC and simply set the page format to A4 with all the default margins CALC then produces a marquee defining the print area.

If I focus the first cell in row 1 outside the marquee and then select all cells to the right with CTRL+SHFT+RIGHT and then “HIDE” the columns using the context menu, the process is instantaneous.

If I then focus the first cell in column A outside the marquee and select all the cells to the bottom and “HIDE” the rows using the context menu, the "HIDE" process takes 4 minutes plus. FOUR MINUTES PLUS - sorry, not shouting, just can't remember how to highlight anymore - Libre Writer does it for me ;)).

If I reverse the processes using the toolbar button, the inference is that I’m undoing row height/column width changes and the process is also instantaneous for both UNDOs.

However;

If I select the columns and >Data>Group and Outline>Group them, then use the activating tab to hide them, the process is still instantaneous.

If I select the rows and >Data>Group and Outline>Group them then use the activating tab to hide them, the process is NOW instantaneous.

The UNDO button now infers that I’m undoing “Hide details”.

My observations/questions:

Why is “Hide” claiming to be adjusting the width/height metrics of the column or row, whereas “Group” is claiming to be adjusting the “Hide” characteristics of the related columns/rows?

Why is the "HIDE" process far more efficient when operating on columns than when operating on rows?

Wouldn’t it be a little more systematic/productive to utilise the same procedures for both operations?
Comment 11 Colin 2021-09-15 09:49:27 UTC
(In reply to Colin from comment #10)

> 
> If I open LoCALC and simply set the page format to A4 with all the default
> margins CALC then produces a marquee defining the print area.
> 
>
Sorry, my inference was that I open a new Calc document so it is completely empty.
Comment 12 Timur 2021-09-15 10:15:15 UTC
(In reply to Telesto from comment #9)
> I assume this being covered by bug 144257
I don't think so. No change without multi-threaded calc.
Comment 13 Xisco Faulí 2021-09-15 15:20:03 UTC
Could someone explain which are the steps to follow?
OTOH, the description talks about LibreOffice 7.2 and the earliest version is set to 7.1.x
Comment 14 Timur 2021-09-15 18:00:37 UTC
Steps are in Comment 3 and times in Comment 5, showing problem from 7.2.
Comment 15 Timur 2021-09-30 23:07:25 UTC
I set this to high because it's a regression and a visible one, that makes user lose confidence in LO. I do it as someone who's triaging thousands of bugs, sometimes increasing but also decreasing importance or closing bugs. 
Silent reverting to "normal"  importance means it will be lost in thousands of other bugs, maybe for a better statistics, but for a worse user experience. Changing priority is not a favor to this bug. Bibisect is, inviting someone to fix is.
Comment 16 Buovjaga 2021-11-13 14:50:46 UTC
I can only bibisect on Linux for now and based on comment 5 there is not enough perceivable difference to do it. Someone else could bibisect on Windows https://wiki.documentfoundation.org/QA/Bibisect/Windows
Comment 17 Timur 2022-04-06 14:14:31 UTC
I see improvement with 7.4+, action is 3-4 secs in Windows, I wrote 12 before. 
I bibisected (one) improvement in 7.3 to source sha:a0e27322bebf5443ef895cb4c43d9288bcf13f9f "use even hyper-thread cores for Calc threading" by Luboš.

Time is comparable to Excel, which has a "Large Operation" warning: "The operation you are about to perform affects a large number of cells and may take a significant amount of time to complete. Are you sure you want to continue?"
Excel may have a trick, I see some data sooner and busy cursor for a while.

But in general, this seems reasonable. I will still call Luboš for comment.
Comment 18 Timur 2022-04-26 11:49:01 UTC
I close as WFM. Luboš, please see.
Comment 19 Luboš Luňák 2022-05-03 14:49:11 UTC

*** This bug has been marked as a duplicate of bug 144777 ***