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
