I was going to fill in a government form at https://www.pomahameludom.sk/ called Vykaz_opatrenie_2_02_2021.ods (the link is called "Výkaz vo formáte ODS (961 KB)" in the section "2) SZČO, ktorým poklesli tržby") and it repeatedly made LO unresponsive. Having inspected the file, I found a 227408K content.xml file inside, mostly consisting of empty rows.
Steps to Reproduce:
1. Open Vykaz_opatrenie_2_02_2021.ods
User Profile Reset: No
Created attachment 170639 [details]
Version: 22.214.171.124.alpha0+ / LibreOffice Community
Build ID: 5262a9e88037decc26da84e7fa62f2955d4cdb85
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
How long does it take for you ?
Created attachment 170642 [details]
Merged Cell removed
The problem is caused by one huge merged cell, which merges range B20:I1048576
into one single cell. Removing that merged cell finally ends up in content.xml of roughly 85 kB. See attachment.
(In reply to Uwe Auer from comment #3)
> into one single cell. Removing that merged cell finally ends up in
> content.xml of roughly 85 kB. See attachment.
Commenting my own comment: "Removing" is an imprecise phrase here. Of course it should mean that I broke up the merging of cells B20:I1048576 and re-created a merging of cell range H20:I20 into a new merged cell.
Excel 365 it's not able to open the file.
(In reply to Xisco Faulí from comment #2)
> to open.
> How long does it take for you ?
In the end it *did* open (after about five minutes of LibreOffice being just a grey window not reacting to clicks and not updating itself), but because the sheet was password-protected, I was unable to edit it from LibreOffice directly — I had to unzip it and remove password protection by sed (vim loaded the file but became unusable).
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":
don't bother scanning nonexistent data (tdf#141182)
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:
Affected users are encouraged to test the fix and report feedback.
it took 30 sec for opening the file in
Version: 126.96.36.199.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
Here is the mac mini 2014 with 2core Intel i5
before the fix it takes
and after it takes
Unfortunately there was a performance regression before the fix introduced by:
author Justin Luth <firstname.lastname@example.org> 2021-12-08 14:22:01 +0200
committer Justin Luth <email@example.com> 2021-12-11 07:20:35 +0100
commit 297ab561c6754f89326a1e8ce1751233669578d7 (patch)
parent 489d7298d2e609ee5900f05ba0064845a7a551ce (diff)
tdf#128895 sc xmlimport: create enough dynamic cols if props
Before this commit, the import time was
so even after Luboš' fix, it takes longer than before 297ab561c6754f89326a1e8ce1751233669578d7. Reopening...
(In reply to Xisco Faulí from comment #10)
> Unfortunately there was a performance regression before the fix introduced
> commit 297ab561c6754f89326a1e8ce1751233669578d7 (patch)
> tdf#128895 sc xmlimport: create enough dynamic cols if props
> so even after Luboš' fix, it takes longer than before
> 297ab561c6754f89326a1e8ce1751233669578d7. Reopening...
Then this is the Jumbo Sheets problem, and it (a) needs an own issue (this one is fixed, the mentioned regression is separate), and (b) it needs to block bug 133764.
(In reply to Mike Kaganski from comment #11)
> Then this is the Jumbo Sheets problem, and it (a) needs an own issue (this
> one is fixed, the mentioned regression is separate), and (b) it needs to
> block bug 133764.
Well, Xisco was seeing this without enabling Jumbo mode, so I don't think it is necessarily a Jumbo issue (although certainly that would make it even worse). And my patch wasn't a jumbo-fix either.
I don't see my commit as a true regression, but the end result just shows another case where calc needs to improve performance.
Having a 200+MB content.xml file is a bit of a failure in its own right. On the machinery I have to work with, I haven't found any GUI tool that lets me inspect that file (without crashing on load). So I'm washing my hands on this one. I have no problems having my patch reverted if that is deemed valuable at this time.
(In reply to Justin L from comment #12)
> I haven't found any GUI tool that lets me inspect that file (without crashing on load).
'xmllint --format file > file2' and view it as a normal text file.
> I have no problems having my patch reverted if that is deemed valuable at this time.
I see no reason for reverting it, correctness is more important than speed. And moreover I cannot reproduce, the file loads in 20s on my Ryzen 2500U.
And I've also pushed a fix that makes the workaround from 297ab561c6754f89326a1e8ce1751233669578d7 unnecessary. So I consider this fixed one way or another, if there's still some related problem, please file a new bugreport.
(In reply to Luboš Luňák from comment #14)
> And I've also pushed a fix that makes the workaround from
> 297ab561c6754f89326a1e8ce1751233669578d7 unnecessary. So I consider this
> fixed one way or another, if there's still some related problem, please file
> a new bugreport.
Version: 188.8.131.52.alpha0+ / LibreOffice Community
Build ID: dddee125cc32f1ad5228e598a7de04e9654e65c1
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Thanks for fixing this issue!!