[Libreoffice-bugs] [Bug 144592] New: CALC performance degradation comparing “Hide rows” versus “Group rows” followed by conceal

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sat Sep 18 18:48:21 UTC 2021


https://bugs.documentfoundation.org/show_bug.cgi?id=144592

            Bug ID: 144592
           Summary: CALC performance degradation comparing “Hide rows”
                    versus “Group rows” followed by conceal
           Product: LibreOffice
           Version: 7.2.0.4 release
          Hardware: x86-64 (AMD64)
                OS: Windows (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: that.man.colin at gmail.com

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210918/e1eef39b/attachment.htm>


More information about the Libreoffice-bugs mailing list