Description: If a spreadsheet contains many (~250) sheets, saving it to XLSX takes a rather long time. Steps to Reproduce: 1. Open Settings – Calc – Defaults and change the number of sheets in a new document to 250 2. Create a new spreadsheet. 3. Save it to XLSX Actual Results: The save takes about 20 seconds in LO 6.2.0. In LO 6.4master it is still about 15 seconds. Similarly it takes 15-20 seconds in: Verzió: 5.0.0.5 Build az.: 1b1a90865e348b492231e1c451437d7a15bb262b Területi beállítások: hu-HU (hu_HU) Verzió: 4.2.0.4 Build az.: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 Verzió: 4.1.0.4 Build az.: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 It’s much better, about 5 seconds in: Verzió: 4.0.0.3 (Build az.: 7545bee9c2a0782548772a21bc84a9dcc583b89) Expected Results: It should happen faster than that. Excel can do this on the same machine in < 1 second. Reproducible: Always User Profile Reset: No Additional Info: LibreOffice details: Version: 6.4.0.0.alpha0+ (x86) Build ID: 49422a469646ad8be43ba828ca24c2484c26b9e8 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-07-08_00:50:19 Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL
Created attachment 152708 [details] Example file from Calc
Thank you for reporting the bug. I couldn't reproduce the bug in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 It takes less than 2 seconds to save empty file with many sheets.
Created attachment 152767 [details] Screenshot of system monitor on Ubuntu during xlsx save It's also slow on my local master build (but maybe because of the debug build), saving takes about 2 MINUTES: Verzió: 6.4.0.0.alpha0+ Build az.: a871265f202255702541e990d67b605d778d5a92 CPU szálak: 4; OS: Linux 4.15; Felületmegjelenítés: alapértelmezett; VCL: gtk3; Területi beállítások: hu-HU (hu_HU.UTF-8); UI-Language: hu-HU Calc: threaded
it takes ~8 seconds in Version: 6.4.0.0.alpha0+ Build ID: fe00a724a918606e5c8c2c32b155bc50b33d56bd CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Gabor, could you please try with a non-debug build ?
about 15 sec in Version: 6.4.0.0.alpha0+ (x64) Build ID: 0d90da9ea0a23c9c4afac62025208559b1496a0e CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;
(In reply to Xisco Faulí from comment #4) > it takes ~8 seconds in > > Version: 6.4.0.0.alpha0+ > Build ID: fe00a724a918606e5c8c2c32b155bc50b33d56bd > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > @Gabor, could you please try with a non-debug build ? That is consistent with the original report. I still got 14 secs in bibisect-win64-6.4: Version: 6.4.0.0.alpha0+ (x64) Build ID: 632ee9aae6d5f3cf08b6d6b2789310c20db713b7 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: threaded This is not a debug build. I guess this could be one of a hundred things that make LO feel sloppy "sometimes".
Hello NISZ LibreOffice Team, Any chance this can be bisected in order to have more input about it ?
On my system with slow disk, LO 4.0 takes 6 sec and Lo 6.4+ takes 16 sec.
Created attachment 155340 [details] Flamegraph Here's a Flamegraph with master sources updated today.
hello NISZ LibreOffice Team, Since you know how to bisect issue, could you please bisect this one ?
Bibisected with bibisect-41max to: bibisect-41max$ git log commit fe3e708b9f0e71312b0b1b2764313c52e296e0fc Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:25:49 2015 +0800 source-hash-9327467a2c5537613fa59013258532028da9c43b commit 9327467a2c5537613fa59013258532028da9c43b Author: Noel Power <noel.power@suse.com> AuthorDate: Tue Jan 29 13:50:05 2013 +0000 Commit: Noel Power <noel.power@suse.com> CommitDate: Wed Jan 30 18:01:45 2013 +0000 better default row detection ( associated with fdo#55621 ) previous patch associated with fdo#55621 compared single instances of row heights to determine the default height, it didn't take into account though repeated rows. Additionally the limit of rows heights ( where rows were empty ) considered when exporting xlsx was the old 65535 limit. On a Ubuntu 14.04 VirtualBox machine the commit before this saves the example file in about 3 secs: commit f99f5974270363cc25b6f59cfb854dec63552860 Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:25:48 2015 +0800 source-hash-bd2c4e8dc42c04eb05adfa32a0d5ce9c72bcfd5d But with this it takes about 13 secs. Clickable link to the suspected commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9327467a2c5537613fa59013258532028da9c43b
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8030b9cf1c55cbbf9be8bf0cee0a408ff0a14710 compress RowHidden()/GetRowHeight() use in excel export (tdf#126326) It will be available in 7.4.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.
It still takes a long time for me in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 7ac19fbce8a35f559eebb879cd0f232bfc95e703 CPU threads: 4; OS: Mac OS X 12.1; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Jumbo Still around 20 sec for saving as XLSX
It takes about 5 seconds in today's nightly: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7ac19fbce8a35f559eebb879cd0f232bfc95e703 CPU threads: 14; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded But the same version is significantly slower, about 35-40 seconds, with Jumbo sheets enabled: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7ac19fbce8a35f559eebb879cd0f232bfc95e703 CPU threads: 14; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Jumbo
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/58c6a36bfcc853ca9da81fbc2d071fa50585655b optimize repeated std::vector removal (tdf#126326) It will be available in 7.4.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.
Created attachment 178702 [details] Flamegraph Here's an updated Flamegraph with master sources updated today (794b93daa9bc31f4ca78d5d88a8dafb12f7ff869) so it includes "optimize repeated std::vector removal (tdf#126326)". Just for information, locally I don't see any slowliness (Ryzen 5 2600 + 32GB).
Saving took around 4 seconds in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c33fb83a62a4a155f11b082e6eb99d07403c3bb9 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL Jumbo Thanks, Luboš!