Description: LibreCalc: Opening a Calc with some formulas: It writes "adapt Row Height" which is taking ages to load! See Kazam video and the Calc sheet itself. Note: this was opened very quickly in previous Libre Calc ps. Version: 6.2.1.2 Build ID: libreoffice-6.2.1.2-snap1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: el-GR (el_GR.UTF-8); UI-Language: en-US Calc: threaded Steps to Reproduce: 1.open the calc sheet in atatchment in Libre Calc6.2 2. 3. Actual Results: Very slow to open a calc sheet with formulas Expected Results: Quick ope of the calc file. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.1.2 Build ID: libreoffice-6.2.1.2-snap1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: el-GR (el_GR.UTF-8); UI-Language: en-US Calc: threaded
Kazam Video of the process: https://upload.cat/9d2c64fe8efe70e0 the Calc sheet itself: http://www.filedropper.com/a2means
Created attachment 149998 [details] OPs example file attached here to BZ Processing this large sheet on Windows is no faster, also gets held up with "adapt row height" processing. Noticeable difference in handling between recent master/6.3.0alpha0+ and the 6.2.2.1 release build Version: 6.3.0.0.alpha0+ (x64) Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09 Locale: en-US (en_US); UI-Language: en-US Calc: threaded Version: 6.2.2.1 (x64) Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
better in master, but still issue. On same system with 5.3.7.2 opened without "adopt row height" processing. Version: 5.3.7.2 (x64) Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group
Here, Kazam video from opening the same file in Libre Office6.1.5.2 It takes less than some seconds 16 seconds vs 93seconds! ! Huge difference! video: https://ufile.io/rsb0j ps. Version: 6.1.5.2 Build ID: 1:6.1.5~rc2-0ubuntu0.18.04.1~lo3 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: el-GR (el_GR.UTF-8); Calc: group threaded
i checked with my notebook (Win10Pro x64, Core-i5-3320M 2,6GHZ,8GB, 256GB SSD) and settings: - OpenGL/OpenCL: disabled - Recalculation on File Load [Always recalculate] - CPU threading settings: disabled LO 5.4.7.2: ~40s LO 6.0.7.3: ~40s LO 6.1.5.2: ~65s LO 6.2.2.1: ~65s
So, if I force sheet to not update row heights--it loads immediately after calculating formula values. A work around, but done by: 1. opening sheet 2. cursor focus into a cell with default row height (I used the first cell under the Indexing tables column) 3. select All cells 4. apply format from main menu Format -> Rows -> Height (the value shows 0.21 ") 5. save to a new ODS file Open the newly saved version. Seems the SC doc shell then does not call the SetOptimalHeight() or SetOptimalHeightOnly(), and so the document opens to screen with no delay after "calculating" of cell formulas completes. Speed is restored, but lose "optimal" font resize to fit results.
bibisected using the bibisect-linux-64-6.2 repo: 5d007cfc8733799cf0535eac3e482eb8cae4b908 is the first bad commit commit 5d007cfc8733799cf0535eac3e482eb8cae4b908 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Jun 8 00:50:11 2018 +0200 source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b author Vasily Melenchuk <Vasily.Melenchuk@cib.de> 2018-04-06 20:19:10 +0300 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2018-06-08 00:47:06 +0200 commit 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b tdf#62268: allow row height recalculation on document load During document load rows with style:use-optimal-row-height="true" should recalculate it's height. Adding Vasily Melenchuk to CC, would you please take a look. git bisect log # bad: [8b2cf76950e32ea46ff293ce75177841ad920e38] source 1149d20ce9f8682b58f98d3fa3bf289fc5974087 # good: [f741463dfe1900d3acf87b538c0c043e42bc523d] source 3a801799536e6870f2fb111b1cc00b9575a35a39 git bisect start 'master' 'oldest' # bad: [f2a6a57cb2d0fbe45c9cfafdcf33a816c6ced63f] source da8617d69a7b27a3eeb3f26e207ddf1b4de3eeb3 git bisect bad f2a6a57cb2d0fbe45c9cfafdcf33a816c6ced63f # bad: [78b09b863133636196066d09bd1098bfd320b0e5] source 064c86b817c5d122af13f1bde26b51a992bf1fd9 git bisect bad 78b09b863133636196066d09bd1098bfd320b0e5 # bad: [350471d334577c65ef95c1ea1799eb8e83b340bc] source 2c85607101e2e04e870e3b87362f39f9a9148e6c git bisect bad 350471d334577c65ef95c1ea1799eb8e83b340bc # good: [6ba40cbc247af171132dc96e7e110c3b73c1e32a] source 18a8cac57d5450fef9111fa356839f07c7593ad0 git bisect good 6ba40cbc247af171132dc96e7e110c3b73c1e32a # bad: [458d44d3be1e40259a480a7bbd2acce49d2df3f9] source ba8c14f488a0bf9f1b10b5f1a24a367b8b98caf6 git bisect bad 458d44d3be1e40259a480a7bbd2acce49d2df3f9 # bad: [e5b96fbf312c88038a5109cd5a2cc1f7e931fed4] source 6c41b664cca6d6985b6f619f83cd103206c5a109 git bisect bad e5b96fbf312c88038a5109cd5a2cc1f7e931fed4 # bad: [12c296faec160c1166ae71e610cdb8778f3ec4af] source 8fef261588c40b8bd85395650afbaf0c9dbdac72 git bisect bad 12c296faec160c1166ae71e610cdb8778f3ec4af # good: [45ee446cead7f889e05cc3f73738285faa78fb56] source 6b8915816242215208e1bb18cfbf01ae85619c46 git bisect good 45ee446cead7f889e05cc3f73738285faa78fb56 # good: [13760daeb59ff9bd2e4ecc973e108fea7a418b55] source fccc7aebb5285e36530b14001e37b33b586365f9 git bisect good 13760daeb59ff9bd2e4ecc973e108fea7a418b55 # bad: [3bdbc761ffeaf9fbd913659c0499568e123d1ed2] source f81714d8e70569506bd10cffc9dc6c18d7c6966f git bisect bad 3bdbc761ffeaf9fbd913659c0499568e123d1ed2 # bad: [5d007cfc8733799cf0535eac3e482eb8cae4b908] source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b git bisect bad 5d007cfc8733799cf0535eac3e482eb8cae4b908 # good: [a3266d604bbc628c822dd1dde60bde3004fbd9fd] source b9dde4a74cba5a771cbc85880d518f6717d19216 git bisect good a3266d604bbc628c822dd1dde60bde3004fbd9fd # good: [2fee85293f3c389834856f15f96e86ff537cee82] source 2a7f74900fb646235b74d4c9bd4690e44edc3ed4 git bisect good 2fee85293f3c389834856f15f96e86ff537cee82 # first bad commit: [5d007cfc8733799cf0535eac3e482eb8cae4b908] source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b ---- MORE INFO: with a dbgutil build on master today, when open this file I get the following warning in terminal: warn:sc:9128:9128:sc/source/filter/orcus/orcusfiltersimpl.cxx:149: Unable to load styles from xml file! failed to load
So does fix for bug 62268 need revisit? Seems if all rows with cells are assigned the "style:use-optimal-row-height='true'" we're doing the correct thing of parsing each row before rendering. Isn't issue then that all rows of a close to empty sheet receive that style as default? It sets them to default, but parses each for cell content--expensive. Simple fix might be to change default row style to "style:use-optimal-row-height='false'"--and only explicitly set it for rows with cell content?
*** Bug 125499 has been marked as a duplicate of this bug. ***
Still present in latest libreoffice My 5 MB calc file take 45 min to load completely (Intel© Core™ i3-3110M CPU @ 2.40GHz × 2 with 4 GB RAM ) Tried with Linux Mint 19.1 & LO 6.3.3
i checked with my notebook (Win10Pro x64, Core-i5-3320M 2,6GHZ,8GB, 256GB SSD) and settings: - OpenGL/OpenCL: disabled - Recalculation on File Load [Always recalculate] - CPU threading settings: disabled Version: 6.1.6.3 (x64) Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: Version: 6.2.8.2 (x64) Build-ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: Version: 6.3.3.2 (x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: all versions need ~65 sec to load but Version: 6.0.7.3 (x64) Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: needs only ~40 sec
@Eike, Kohei -- do you have any thoughts for use of "style:use-optimal-row-height='true'" so it would not be as expensive as it is now?
The recalculation of heights effectively performs full recalc (so it takes the same time Ctrl+Shift+F9 take). This makes cached values in own format useless.
I believe the underlying problem is that Calc would somehow assign style:use-optimal-row-height='true' to all & sundry. I *think* we had that fixed at some stage, at least cannot repro with some simple documents anymore in 6.4. Any second thoughts on that? If the above is *still* an issue (perhaps with a more complex setup), I'd love to hear.
putting it back to NEW ( NEEDINFO status is incorrect here ) Before 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b the issue can also be reproducible if recalculation on File Load for ODF files is set to Always Recalculate in Tools/Options.../LibreOffice Calc/Formula in Version: 6.0.0.0.alpha1+ Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group threaded it takes real 2m26,267s user 2m20,015s sys 0m3,418s with the option enabled and real 1m6,187s user 0m54,940s sys 0m7,024s with it disabled
For the record, it takes real 2m26,906s user 2m24,253s sys 0m2,676s in Version: 7.0.0.0.alpha0+ Build ID: bc994a4b01cf61444452bb377010c7c4cc377698 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
and real 2m38,464s user 2m29,478s sys 0m5,677s in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.19; Render: default;
*** Bug 56564 has been marked as a duplicate of this bug. ***
Increasing priority.. * Not good for the general impression.. * Obvious since LibreOffice 6.2
1. Open attachment 142401 [details] (XLSX)-> Opens fine 2. Save to ODS & reopen..
Another one: attachment 154545 [details]
I am the same person that I opened this bug. I downloaded LibreOffice dev 7. The problem remains. It took almost 2 whole minutes to open it! ps. CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: el-GR (el_GR.UTF-8); UI-Language: en-US Calc: threaded Example ods File which remains for 30 days for download: https://ufile.io/qc3zs2ra
In given document we have tons of rows with style:use-optimal-row-height="true" and these rows should be recalculated to find this optimal height. Once I remove this style from rows document begin to load in acceptable time. So feature works okay from technical point of view. At the same time attempts to set optimal height from UI also very slow. Maybe it requires some profiling & optimization. While this is quite often case (this value is set by default in many cases) it makes sense to adjust adaptation of row height on load further. Out of my head I see several options: * provide per document setting enabling or disabling this feature. With disabled by default we will receive less such problems like current one. * do not calculate on load rows with style:use-optimal-row-height="true" and provided row height. Such scenario should be okay for at least one of original tdf#62268 bugdocs. IMHO row recalculation on load is quite handy only for generated by third-party tools documents. For documents created in Calc it senseless: given height is correct one (otherwise it is a bug). So for generated docs users should just omit style:row-height parameter to force LO to calculate this row height on load.
It's even worse here. I have a document with just a few rows set to "style:use-optimal-row-height='true'" and LO refuses to open the document. It simply crashes. We are running under macOS 10.14.6 and 10.15.6 and we can confirm that it happens with any version of LO > 6.1.6.3 Hope you get this fixed very soon :) Please let me know if I can help somehow.
Quick follow-up : I've done some more testings all this afternoon. After messing a bit with the file with LO 6.1, I finally managed to remove some lines where `style:use-optimal-row-height="true"` was applied... Which led me to being able to open the file with the latest LO (6.4.4.2) - hurray ! Unfortunately, it's then impossible to save the file : LO crashes (no report, no log :-/ ). Is it recalculating the rows height when saving ? (or do I have to look somewhere else ?)
I'm not able to find which lines have `style:use-optimal-row-height="true"` But I think it's more "friendly", especially for low profile users, to add the possibilty to switch that off by some option. Just my two cents.
(In reply to prempa from comment #26) > I'm not able to find which lines have `style:use-optimal-row-height="true"` > > But I think it's more "friendly", especially for low profile users, to add > the possibilty to switch that off by some option. > > Just my two cents. I agree Indeed!
Hi! I found this solution posted in 2013: https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=62365#p345575
*** Bug 140036 has been marked as a duplicate of this bug. ***
it takes 44 sec in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL
(In reply to Roman Kuznetsov from comment #30) opening attachment 169330 [details] ODF archive and editing the content.xml to change the two row styles from 'use-optimal-row-height="true"' to "false" -- the sheet opens in about 5 seconds. With them intact in the original open in 18 seconds. Kevin Suo gives possible approach to fix the regression caused by work on bug 62268 Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: cb2827f5f65324f309fa0e3c30d0b19ad237410e CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Does anybody have any pointers on the history why Calc sets this use-optimal-row-height="true"' for all rows in a new document? FWIW, multi-line Calc cells are one possible reason. Create one, type some text so you get e.g. 3 lines (enable Alignment -> Wrap text automatically) - then change zoom value & see the text line breaking change randomly. How is a Calc user supposed to generate a document with a row-height that exactly matches the needed area, if the row height is not adapted on load then?
(In reply to Thorsten Behrens (allotropia) from comment #32) > Does anybody have any pointers on the history why Calc sets this > use-optimal-row-height="true"' for all rows in a new document? > Nope, and seems unnecessary/non-performant to have it applied to all rows with the style during load. > FWIW, multi-line Calc cells are one possible reason. Create one, type some > text so you get e.g. 3 lines (enable Alignment -> Wrap text automatically) - > then change zoom value & see the text line breaking change randomly. > > How is a Calc user supposed to generate a document with a row-height that > exactly matches the needed area, if the row height is not adapted on load > then? Mixing apples and oranges? Not so sure as the scale on zoom is clean if you enable the Calc general option 'Use printer metrics for text formatting'. Otherwise the recalculate While the tweak done for bug 62268 ( https://gerrit.libreoffice.org/c/core/+/52521/ ) to always process use-optimal-row-height="true" on load is causing the annoyance of slow opening. Wouldn't Kevin's test ( as on https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c38 ) be a reasonable adjustment to correct this?
(In reply to V Stuart Foote from comment #33) > Otherwise the recalculate does not hold the cell content at scale when zooming in or out, and hides or shifts it.
(In reply to Thorsten Behrens (allotropia) from comment #32) See https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c46 In short: by default each row has style:use-optimal-row-height='true'. When you type multiline content in a cell and hit enter, then style:row-height is updated. For style:use-optimal-row-height='false' when you type multiline content the style:row-height is not updated, so that it uses default row height or the old value. In both cases on FILEOPEN the correct style:row-height is used directly, no need to recalculate.
I didn't wrap my head around, neither any possibly underlying problems nor the proposed solution, but the procedure described in https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c12 and mentioned again in https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c47 sounds reasonable to me on first sight. Citing here for completeness: a) if there is no height attribute and the "use_optimal-row-height" attribute is set then calculate the row height b) if there is no height attribute and the "use_optimal-row-height" attribute is not set then use the default value c) if there is a height attribute just use it
This is not a regression, see comment 15
See also https://ask.libreoffice.org/t/row-height-disable-automatic-row-height-permanently/46862
(In reply to Xisco Faulí from comment #37) > This is not a regression, see comment 15 This *is* a regression. In comment 15, you point to the fact that *forced recalculation* takes just as much. But that is not the issue raised here; the low performance of the recalculation itself is a separate issue. Yes, *if* that separate issue were fixed, and recalc took an instant, this issue would *possibly* be also resolved (unless there is another reason to restore cached height even if recalc doesn't take long). But this specific issue is about the problem that had appeared after the commit identified in comment 7, and is specifically about the new behavior of ignoring the cached values, and taking that long time, where it *did not* previously: on file open.
Created attachment 174594 [details] test spreadsheet with large block of numbers
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).
My attachment is at Comment 40
*** Bug 43804 has been marked as a duplicate of this bug. ***
(In reply to casa from comment #41) > 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 No. Your test is *very* important and interesting by its own, but it deserves a separate, dedicated bug report. The fact of "damage" to the cells is a separate bug, and may be the reason why *this* bug started to happen more often - but *this one* is specifically about behavior on opening files with cached height values on auto-height rows. Tbis is completely different place in code.
OK, I will accept suggestion and create new LO bug.
I will add a note to my comments that might be helpful (even though I will make new LO bug ticket). As mentioned before if you preview (or change) the sheet font it will cause 'adapt row height' issue/lag/bug. I just tested saving that spreadsheet and reopening. The lag/bug goes away (the cell/sheet 'damage' disappears) until you preview or change font again, then it comes back.
Created attachment 174723 [details] Example file FWIW I bisected the example file above to this commit and a slow calculation bug 144257, which might be related to (re)calculation performance issue (see comment 39)
For me, on Ubuntu 18.04.6 with LO 7.3.0.2: - Attachment 149998 [details] takes about 20 seconds to open - Attachment 174594 [details] takes about 4 seconds to open - Attachment 174723 [details] takes about 7 seconds to open Version: 7.3.0.2 / LibreOffice Community Build ID: f1c9017ac60ecca268da7b1cf147b10e244b9b21 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I haven't really followed this bug, but from a quick look through the comments, it looks like there's been some improvement?
A proposal for resolving this problem is in gerrit https://gerrit.libreoffice.org/c/core/+/129300 Overall idea is to introduce new document level setting for triggering row height recalculation on load. By default it is off. But it can be important for generated documents, like in original tdf#62268. In this case document generator could set this flag to have prettier generated spreadsheets. All other documents (without proposed document setting) will be loaded without recalculation, like before fixing tdf#62268. Any feedback is welcome.
a new example. 40k rows of text. I am unable to open this document due to adapt row height problem. https://ufile.io/9su6o0t3
Created attachment 178852 [details] example document from comment 50 Uploading document from comment 50. I can confirm that it takes ages to open, stuck at the "Adapt row height" stage, in LO 7.3.1 on Ubuntu 18.04. I gave up after waiting for 5 minutes. Version: 7.3.1.3 / LibreOffice Community Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
In my machine, opened after ~15minutes !!!!!
(In reply to elias estatistics from comment #52) > In my machine, opened after ~15minutes !!!!! developers are in discussion around patch in comment 49 Otherwise bypassing the current "feature" of optimal row heights on a calc sheet is trivial. Need only open the ODS zip archive and change one style string in the comntent.xml Toggle the style stanza 'use-optimal-row-height="true"' to a value "false", and save it back into the zip archive. Document will then open in seconds.
(In reply to V Stuart Foote from comment #53) > (In reply to elias estatistics from comment #52) > > In my machine, opened after ~15minutes !!!!! > > developers are in discussion around patch in comment 49 > > Otherwise bypassing the current "feature" of optimal row heights on a calc > sheet is trivial. Need only open the ODS zip archive and change one style > string in the comntent.xml > > Toggle the style stanza 'use-optimal-row-height="true"' to a value "false", > and save it back into the zip archive. > > Document will then open in seconds. Can you elaborate more on how to do this ? Also how to make it permanent and for all files ?
(In reply to pharmankur from comment #54) > (In reply to V Stuart Foote from comment #53) > > Can you elaborate more on how to do this ? > Also how to make it permanent and for all files ? Two ways. And this is for existing ODF spreadsheets. But work on a copy (just to be safe). One if you have the file open in Calc, see comment 6. The other is if you don't want the delay. Simply open archive with Z-zip, notice the content.xml that is the meat of the document. Select and use 7-zip's Edit (configure 7-zip to use vi, or gvim for editing in advance). Find the string "optimal" (in vi, gvim issue the ex / to find). Cursor to the "true" and replace with "false". Write and quit the edit. 7-zip will detect the change and ask if you want to merge back into the archive. As to making it permanent, not certain but Tools -> Options -> Advanced -> Open Expert Configuration and search for "optimal". Adjust the org.openoffice.Office.UI.CalcCommands stanza: org.openoffice.Office.UI.Commands:LabelType['uno:SetOptimalRowHeight'] Properties long "1" --> "0" That should keep future sheets from including the optimal set optimal row height style.
Thanks for the quick reply ! But it's not working for me somehow. Content.xml itself was about 45 MB While opening it was running for more than 30 min consuming 100% of my one processor core. At the end I had to kill it. I tried changing org.openoffice.Office.UI.Commands:LabelType['uno:SetOptimalRowHeight But it also did not work for any of my existing documents.
Hi i hope i am posting in the right place. I have the same problem with adapt row height taking too long (over 30 minutes sometimes). I have 2 ods files with around 20000 rows and i use index match arrays to get data from one to the other. I did the actions shown in Comment 55 for both my files and that helped: i can save and open them within reasonable time. My problem is when i try to add a new column to fetch new data with index match the "adapt row height" appears again and takes forever. To clarify they way i do it is i enter my formula in the first cell of the column that i want to edit and then i copy paste that cell to the rest of the column. The more columns i add this way the longer it takes each time. I there a way to avoid adapting row height while adding new formulas to columns (not only when opening and saving)? Version: 7.3.1.3 (x64) / LibreOffice Community Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_CY); UI: en-US Calc: CL
*** Bug 150744 has been marked as a duplicate of this bug. ***
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e8fae4d0fb2994a7b4ac00e9da35e1deccb296dd tdf#124098: sc, ods import: do not recalculate row heights It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b57307e8f3553fcb292c9c11fcf58bcef3a6cb3c Related: tdf#124098: sc import, more optimization for row heights It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Balazs Varga committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/ba59e8e3544190f4c1464d2ce18b1386c0d8a678 tdf#124098: sc, ods import: do not recalculate row heights It will be available in 7.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi! I am on LO 7.5.2.2 and the bug is still repeating
(In reply to Oleksa Stasevych from comment #62) > Hi! I am on LO 7.5.2.2 and the bug is still repeating Please be more specific. Which example document did you use? For example, I tested with attachment 178852 [details] and find it is fixed in: Version: 7.5.3.1 (X86_64) / LibreOffice Community Build ID: d29ee673721b12c92b3de9b9663473211414f0db CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2d2974f22ab59ea7dab1aee778308c4f50ff5464 tdf#124098 sc add global config setting "RecalcOptimalRowHeightMode" It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #64) > tdf#124098 sc add global config setting "RecalcOptimalRowHeightMode" This patch has been moved from ScXMLImport to ScDocShell so that other filters can use it. https://gerrit.libreoffice.org/c/core/+/164721