Here I have a spreadsheet that Calc absolutely chokes on. Just opening the file take about 2 minutes of CPU time, while Calc is completely unresponsive. Even after the document is open, all operations are very sluggish and Calc repeatedly locks up and stops responding for many seconds. MS Excel 2016 has no problems opening the file under 10-20 seconds.
Steps to Reproduce:
1. Try to open attached document
2. Observe that it locks up, uses 100% of one CPU core, and after a long time it opens the document
3. Observe that any attempted operation in the document can take a very long time
The file takes forever to open and locks up LO for extended periods of time
The file should open quickly, without excessive CPU usage. LO should not lock up and stop responding while loading the document.
User Profile Reset: No
Verzió: 22.214.171.124 (x64)
Build az.: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU szálak: 2; OS: Windows 6.1; Felületmegjelenítés: alapértelmezett;
Területi beállítások: hu-HU (hu_HU); Calc: CL
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0.4 Waterfox/56.0.4
Created attachment 140660 [details]
document that triggers the issue
Created attachment 140661 [details]
There is a lot of unused cell with direct format, cleaning it the spreadsheet opens fine.
btw the sheet it's protected.
Resolved as works for me, please if you are not agree, reopen it.
(In reply to m.a.riosv from comment #2)
> Created attachment 140661 [details]
> Cleaned spreadsheet
> There is a lot of unused cell with direct format, cleaning it the
> spreadsheet opens fine.
> btw the sheet it's protected.
> Resolved as works for me, please if you are not agree, reopen it.
I have no idea how to clean unused cells with direct format, could you write down how you did it please? (or link a tutorial/guide?)
I also disagree that this is not a bug.
LibreOffice should be fully compatible with MS Office, and thus not being able to open some files that MS Office can open without problems is a huge issue. Ordinary users should never be forced to file a bug report. My mother run into this problem (she has no MS Office on her computer), and she was in complete despair, because she had no idea what went wrong and how to fix it or get information. Issues like this one completely ruin the usability of LO for noobs.
To clear a direct format use Ctrl+M on the selected cells.
As I comment the file is protectod so it's no possible e.g. to see if there are conditional formats slowing the file.
LibreOffice is more oriented to the use of the styles, with all those cells having defined styles is quicker.
Reopen the bug, it's your choice.
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
else confirms it.
Created attachment 140865 [details]
Callgrind output from master
Let's leave it open in case someone wants to optimise things based on this callgrind.
Arch Linux 64-bit
Build ID: 144bc302b8e610422f0bdbfceb1726822454dfbc
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 23th 2018
Uu, this is actually a regression as 3.6 opens it very quickly.
Arch Linux 64-bit
Version 126.96.36.199 (Build ID: e183d5b)
Version 188.8.131.52.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
but not in
Bibisected on Linux with 43all to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=b67a51b40a4876f4bd97a2917103112006710b0c...c33019b36d613f951787ce9836e34d74bfbd6a1b
Has lots of commits from Kohei.
This attachment #140660 [details] got a lot better recently after:
author Noel Grandin <firstname.lastname@example.org> 2019-11-12 16:00:55 +0200
committer Noel Grandin <email@example.com> 2019-11-15 07:19:01 +0100
reduce iteration in ScViewData::GetScrPos
Now the load time is quick and scrolling is not causing lock-up, even though it's a bit slow to begin in:
Version: 184.108.40.206 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU szálak: 4; OS: Windows 6.3 Build 9600; Felületmegjelenítés: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
@Noel Grandin thanks for fixing this!