Bug 144592 - CALC performance degradation comparing “Hide rows” versus “Group rows” followed by conceal
Summary: CALC performance degradation comparing “Hide rows” versus “Group rows” follow...
Status: RESOLVED DUPLICATE of bug 144155
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-18 18:48 UTC by Colin
Modified: 2021-09-20 15:29 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Colin 2021-09-18 18:48:21 UTC
Description:
There is a noticeable difference between the process of selecting & hiding rows utilising the context menu when compared with selecting & “concealing” them utilising the toolbar’s Data menu to group the same rows.
When a large number of rows are simply hidden via the context menu “hide rows” it can take minutes to successfully hide them, whereas selecting the same rows and then grouping them via the menu Data>Group and Outline>Group (F12) will permit their instantaneous concealment.
Importantly, when the context menu “hide rows” is “undone” with the tool button it informs that it is undoing a “row height” formatting command whereas the same undo via tool button for the “group & conceal” action informs that it is undoing “Hide details”.
Clearly a contradiction and probably indicative of an inferior routine being utilised for the context menu “Hide” which is really a metric adjustment and the data menu “group” which proclaims itself to be a hide function.
My experiments have demonstrated that even filling as much of the sheet as possible in 12GB of RAM with a single character in hundreds of millions of cells, has little or no impact upon the timing of either the hide or group functionality. Hiding still sucks whilst grouping and concealing is still virtually instantaneous.
I am defining the speed of operation of the chosen functionality NOT the speed with which either columns or rows are selected, both of which are virtually instantaneous.

Steps to Reproduce:
Open a new CALC document
Format the document A4 and accept whatever are your default margin settings
This produces a marquee on screen depicting the print range.
Select the first cell in row 1 outside the marque
Select all cells to the end of the row with ctrl+shft+right arrow
Right click the column headers and select “hide” from the context menu
Observe that 1000+ columns are instantly “hidden”
Utilise the undo button and the columns reappear instantly
NOTE: the undo button informs that the columns’ metrics are being amended they have not been hidden, their width has been set to an “invisibility” factor.
Select the same columns
Utilising the menu Data>Group and Outline>Group (or F12) them
Conceal them utilising the “control” tab
Hover over the “undo” button and observe that it is intending to “Undo: Hide details”
That is a minor benchmarking exercise

Leaving the columns hidden, concealed or exposed, will have zero impact upon the next steps -although it should be observed that this action has concealed 99.316% of the permissible cells

Select the first cell of Column A outside the print marquee
Select all rows to the end of the sheet with ctrl+shft+down arrow
Utilising the menu Data>Group and Outline>Group (or F12) them - all 1,048,523 of them
Conceal them utilising the “control” tab
Observe the instantaneous response
Hover over the “undo” button and observe that it is intending to “Undo: Hide details”
Undo the action
Remove the grouping (ctrl+F12)
Select the same rows
Right click the row header
Select “Hide rows” from the context menu
Go off and make a cup of coffee because despite LO reporting that it is not responding, it is in fact beavering away in the background resetting the height of 1,048,523 rows to an invisibility factor, as opposed to whatever “group” does to them at the speed of  ---------- an i5 running at 3.4GHz

The one saving grace is that undo is instantaneous.
There is also the obvious workaround – use group instead of hide


Actual Results:
Slow performance of the command

Expected Results:
Fast performance of the command


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
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
Tested on
i5 3.4GHz 12GB RAM & 8GB RAM & 4GB RAM
Comment 1 Xisco Faulí 2021-09-20 15:06:07 UTC
This is a duplicate of bug 144155 and it's fixed in LibreOffice 7.2.1. Please, download it

*** This bug has been marked as a duplicate of bug 144155 ***
Comment 2 Colin 2021-09-20 15:22:07 UTC
(In reply to Xisco Faulí from comment #1)
> This is a duplicate of bug 144155 and it's fixed in LibreOffice 7.2.1.
> Please, download it
> 
> *** This bug has been marked as a duplicate of bug 144155 ***

Odd, If I check for updates in the "help" menu it advises me I'm up to date but when I go onto the download home page it indeed offers me 7.2.1 - is this a bug or a feature?
Comment 3 Xisco Faulí 2021-09-20 15:29:37 UTC
(In reply to Colin from comment #2)
> (In reply to Xisco Faulí from comment #1)
> > This is a duplicate of bug 144155 and it's fixed in LibreOffice 7.2.1.
> > Please, download it
> > 
> > *** This bug has been marked as a duplicate of bug 144155 ***
> 
> Odd, If I check for updates in the "help" menu it advises me I'm up to date
> but when I go onto the download home page it indeed offers me 7.2.1 - is
> this a bug or a feature?

No, it just takes some days until it appears.