I have several ODS spreadsheets that are slow to load because of the "Adapt row height" processing stage. Since the spreadsheet has several sheets, the slowness happens not only when I open the files. As I first change focus to each sheet in a file there's a significant delay before its content is displayed. The same delay happens if I select all ~10 sheets and apply any given change at once (to a formula, conditional formatting, or formatting of the cells). As the change is applied to each sheet it is followed by a delay due to the "Adapt row height" processing. By the way, this "adapt row height" processing happens even when the changes do not affect the content of a cell (e.g. the size of the font), such as pasting in all sheets unformatted text. The most simple sheets contain one VLOOKUP function that references an external ODS file, two SUMPROCDUT functions in a IF function and some conditional formatting base on formulas that contain IF, OR, and AND funtions.
The problem still occurs with the version 3.5.0 RC2 (Windows 7 - 64 bits).
Agree - LibO 3.5 RC2: this bug is VERY annoying when working on sophisticated spreadsheets (e.g. (array) formulas, conditional formattings, large amount of data) - no solution so far.
I can agree with that, and I'm afraid this slow down of computing time directly affects LibO's acceptance to be the software of choice when migrating xls to ODS. OOo computes faster at the moment than LibO concerning the same ODS having this LibO-effect.
Can you please attach test documents. Otherwise it is impossible to fix the problem. And matrix formulas should be much faster in 3.5.3 and master.
Closing Bug due to reporter's inactivity @reporter: Please feel free to reopen this bug if you find out that the problem still exists with the current stable LibreOffice version and if you can contribute requested additional information due to <http://wiki.documentfoundation.org/BugReport> (especially BugReport Details)!
Still occurs with the following versions: 1. LO Calc 6.2.8.2 and 6.2.8.2 (64bit) on Linux Mint 18.3 (64bit) MATE 2. LO Calc 6.3.3 (64bit) on Linux Mint 19.1 (64bit) MATE 3. LO Calc 6.3.2 (64bit) on Windows Server 2012 R2 (64bit) Expected Behaviour: 1. Numerical data with no text data using these operations occurs in seconds. 2. Excel (32bit) processes within seconds for both numerical and test data. 3. The user should have choice whether "Adapt row height" is performed by default. Observed Behaviour (as previous posts): 1. When using large spreadsheets with many calculations then operations such as opening files and inserting columns (amongst others) results in processing times in excess of 5 minutes to over 30 minutes depending on the spreadsheet and hardware when using LO Calc. (Excel on same hardware may take up to 5 minutes or so.) 2. LO Calc indicates "Adapt row height" or provides no message but is unresponsive. 3. LO Calc uses just 1 core/threads at 100% - no other cores are used. In comparison LO Calc uses all cores when performing calculations. (Also Excel uses all cores/threads when performing operations comparable to "Adapt row height.) 4. It is not possible to prevent "Adapt row height" from occurring automatically and by default - hence there is no workaround. Temporary relief is possible by selecting the entire worksheet then unchecking the 2 tick boxes for automatic row and height adjustment. This is described for row height at the link below and needs also to be done similarly for column width. Refer to: https://ask.libreoffice.org/en/question/9348/calc-restore-row-heights-to-automatic-to-max-content-height/ Reproducibility: 1. Spreadsheets effected always show this behaviour. 3. I could provide a spreadsheet for a developer to look at for diagnosis purposes but not for general publication. Further details: I have posted hardware and other details at: https://ask.libreoffice.org/en/question/218518/row-height-disable-automatic-row-height-permanently/
... I forgot to mention that one of the key characteristics causing this excessive processing time for "Adapt row height" appears to be long text strings or text strings with soft line returns (inserted using "CTRL ENTER"). Possibly other factors such as conditional formatting is involved. I have not been able to reproduce adequately this in a test worksheet (yet ...?).
I have a VERY simple test case which demonstrates what appears to be the issue in this ticket. It does not involve open/loading of a file and is easily replicate with ONLY a plain/default spreadsheet having a block of numbers and then attempting to change the font. (Actually changing the font isn't even necessary!) REPLICATION (using LibreCalc v7.1.5.2 x86 on windows 10): I have attached "bug-adaptRowHeight.ods" which is nothing more than a default blank ODS spreadsheet with a large block of numbers. No formatting or anything. (If you think something is weird about this spreadsheet then just copy "numbers only" or "unformatted text" to your own new/blank spreadsheet instead and follow test.) This bug isn't as noticable if you only have a small spreadsheet with a few cells and that is why this spreadsheet (or similar large one) is useful. OBSERVATION: with this spreadsheet open, use the arrow keys to move the cursor from cell to cell; notice there is no lag, no delay, and no flickering "adapt row height" message or progress bar appearing at the bottom. TEST STEP: Now select the entire spreadsheet and then click the font name drop down arrow (as though you wanted to change the entire sheet's font). The list of available fonts will drop open and the current sheet font will be highlighted (Liberation Sans). Now...use the down arrow key to move the highlight selection to then next font. So (on my machine) "Liberation Sans" is highlighted and the font under it is "Liberation Sans Narrow". Thus, press down arrow to highlight to it (but don't select). When you highlight "Liberation Sans Narrow" (or whatever font you have below the default; doesn't matter) LibreCalc will preview that font on the spreadsheet (but not actually change it yet; you would have to press enter). Instead, press ESC to leave the font dropdown and *NOT* make any changes to the spreadsheet. The entire spreadsheet is still "Liberation Sans". BUG: again move the cursor around with arrow keys and notice there is now a delay and sluggishness! Each move from cell to cell has a pause and also you will see the bottom of screen flicker words "adapt row height" with a quick green progress bar. You didn't even change the spreadsheet, but just the act of previewing a different font has now permanently made the spreadsheet operate with a lag. NOTES: I have not found a way to reverse the program/cell 'damage' once the lag starts (after preview or font change). Since you didn't actually change the cells or font or formatting you can't just hit CTRL-Z to Undo. There is nothing to undo! You have to close the spreadsheet and reopen it to return to having no lag or no 'adapt row height' situation. I have not found that program font settings (options) matter to this bug (anti-aliasing, use skia, show preview of fonts, etc). The default/starting font of your spreadsheet or the font you preview doesn't seem to matter. It is the act of previewing or changing from the starting/default font (on cells with contents) that breaks something. (I used numbers, but presume text or formula contents have same issue.) What matters is starting with a new/default/blank spreadsheet where the cells are untouched by any font actions. Cursor movement will be fine. Then paste in numbers (without formatting; "paste numbers" or "unformatted text") and THEN preview or change font at which point the bug appears. The cells appear to require contents and need to be 'touched' by the font preview (or change) in order to be 'damaged' and cause 'adapt row height' problem. Instead, if you take a default/new/blank spreadsheet, select the spreadsheet, and preview or change the sheet font BEFORE it has contents, and THEN paste a block of numbers ('paste numbers' or 'unformatted text') there will be no problem. The pasted numbers will (properly) be in the new font and the delay/sluggishness "adapt row height" bug/problem will NOT happen. (But if you THEN preview a different font it will.) I am filing this bug comment under both: 124098 and 43804 (which somebody reopened and appears to cover same issue).
Created attachment 174595 [details] test spreadsheet with large block of numbers
*** This bug has been marked as a duplicate of bug 124098 ***