Description: Insert rows 100 times slower in 7.1.5 compared to 7.1.4, instantaneous in 7.1.4, 5 seconds in 7.1.5. Same command and same spreadsheet. Steps to Reproduce: Insert 2 columns in a small spreadsheet Actual Results: as expected but after 5 seconds Expected Results: What I got, but too slowly Reproducible: Always User Profile Reset: No Additional Info: May be connected to bug 144155, but Hide rows is instanteous in 7.1.5. Several other commands are slow: entering a new formula filling a series filling down Insert column 5 seconds Version: 7.1.5.2 (x64) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 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 Insert column instantaneous Version: 7.1.4.2 (x64) / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 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
(In reply to David Lynch from comment #0) > Description: Insert rows > Steps to Reproduce: Insert 2 columns in a small spreadsheet Is it rows or columns or both? I don't see it. Is it with any Calc file? Please try User Profile Reset/rename and try LO master from https://dev-builds.libreoffice.org/daily/master/current.html.
Created attachment 174675 [details] See comment 2 See comment 2
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)
[Automated Action] NeedInfo-To-Unconfirmed
> 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.
Hi David, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
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
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
(In reply to David Lynch from comment #8) > 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 I assume this being covered by bug 144257
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?
(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.
(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.
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
Steps are in Comment 3 and times in Comment 5, showing problem from 7.2.
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.
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
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 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.
I close as WFM. Luboš, please see.
*** This bug has been marked as a duplicate of bug 144777 ***