Created attachment 119985 [details] confidencial finantial information I have problems with the attachment file, with this file normally work (but with ms office), now I trying to make a change in LibreOffice and save it, but then LibreOffice crashes.
I can confirm with LO 5.0.2.2 and LO Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89); win7 I can confirm with LO Version: 5.1.0.0.alpha1+ Build ID: 233b9b0ec95069b5ce98aab942304459ca7344a8 Lo quickly eats 1,6GB of memory and doesn't respond.
*** This bug has been marked as a duplicate of bug 66668 ***
Fix from bug 66668 didn't fix this one.
Version: 5.4.0.3 (x64), Build-ID: 7556cbc6811c9d992f4064ab9287069087d7f62c, Win10: Does not crash, but is busy during save as „Microsoft Excel 2007-2013 XML“ for a while (1-2 minutes?) Eats up more than 2.2 GBytes(!) of RAM while saving, then returns to normal behaviour an frees the RAM. Obviously something need to be optimized.
This is a circuclar reference file, but that's not a cause. XLSX without circ. fer. is also slow. Valgrind needed, I guess.
Created attachment 145140 [details] Callgrind output from master From saving Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 8b1501d80dc9d3f42c351c6e026fa737e116cae5 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 23 September 2018
Created attachment 150884 [details] Perf flamegraph of saving Pretty nice plateaus in there Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 18 April 2019
Created attachment 158580 [details] doc saved as ods in LO 6.4.1.2 doc saved as ods in LO 6.4.1.2 x64 win 10-64 no problem here
Tested saving to XLSX (the original problem) and it only takes like 10 secs, so WFM is correct status. Arch Linux 64-bit Version: 7.0.0.0.alpha0+ Build ID: 08334285ec9c7d5356f4b89192a5fba6e6733328 CPU threads: 8; OS: Linux 5.5; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 8 March 2020
I have a slow Linux test system and it takes 50 secs with master a11c10a83f6fceae6cfb519725d06f8eaf1013fb of yesterday. And oldest 7.0+ was 60 secs, just slightly better. Saving from XLSX to XLSX. I'll set New until retested.
master 7.0+: real 0m54,719s user 1m56,268s sys 0m5,638s master 7.0+ with file overwrite: real 0m57,447s user 1m54,335s sys 0m5,673s oldest 7.0+ with file overwrite: real 0m54,229s user 1m48,155s sys 0m5,854s I guess those numbers confirm what I wrote ,please correct if not.
Created attachment 158624 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
save as xlsx has a slow point of about 10 sec. with below ver, but no mem problem or crash, wouldn't have commented but if the document contains real world data - didn't test but looks like - id recommend to pull it back, in many states spreading of such private information is a verdict ... Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
seems ok with also 10 sec in 7.0.0 beta2 x64 in win 10 x64
*** This bug has been marked as a duplicate of bug 140893 ***
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f8edf0a94e9608d7e7d8ed5fb46036b2ceb71693 try to avoid using map when searching most used item (tdf#95346) 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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4e279e8c4986ca3de79bea2216c5783cb113a5bb reuse a vector instead of repeatedly creating it (tdf#95346) 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.
Luboš, please explain why it's marked a duplicate of bug 140893 when it's not resolved with that, still 2,5 GB or RAM in saving. Also, you had other patches, so I guess Fixed would be a better status.
Several sheets contain a value in the last row. The export filter needs to process all rows because of that and the internal representation needs that memory. I don't see this pathological case worth the effort of doing something about it.