Bug 116425 - FILEOPEN XLSX Excel spreadsheet takes forever and a lot of CPU time to open
Summary: FILEOPEN XLSX Excel spreadsheet takes forever and a lot of CPU time to open
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:xlsx, haveBacktrace, perf, regression
Depends on:
Blocks: XLSX
  Show dependency treegraph
 
Reported: 2018-03-15 20:20 UTC by clogged.drainpipe
Modified: 2020-10-05 12:23 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
document that triggers the issue (395.24 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2018-03-15 20:26 UTC, clogged.drainpipe
Details
Cleaned spreadsheet (59.22 KB, application/zip)
2018-03-15 23:41 UTC, m_a_riosv
Details
Callgrind output from master (5.61 MB, application/x-xz)
2018-03-24 19:40 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description clogged.drainpipe 2018-03-15 20:20:41 UTC
Description:
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

Actual Results:  
The file takes forever to open and locks up LO for extended periods of time

Expected Results:
The file should open quickly, without excessive CPU usage. LO should not lock up and stop responding while loading the document.


Reproducible: Always


User Profile Reset: No



Additional Info:
Verzió: 6.0.2.1 (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
Comment 1 clogged.drainpipe 2018-03-15 20:26:21 UTC
Created attachment 140660 [details]
document that triggers the issue
Comment 2 m_a_riosv 2018-03-15 23:41:03 UTC
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.
Comment 3 clogged.drainpipe 2018-03-16 13:03:21 UTC
(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.
Comment 4 m_a_riosv 2018-03-16 23:15:00 UTC
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.
Comment 5 Xisco Faulí 2018-03-19 15:27:54 UTC
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
else confirms it.
Comment 6 Buovjaga 2018-03-24 19:40:31 UTC
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
Version: 6.1.0.0.alpha0+
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
Comment 7 Buovjaga 2018-03-24 19:41:58 UTC
Uu, this is actually a regression as 3.6 opens it very quickly.

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 8 Xisco Faulí 2018-03-25 15:22:45 UTC
Reproduced in


Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

but not in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 9 Buovjaga 2018-07-07 14:38:17 UTC
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.
Comment 10 NISZ LibreOffice Team 2020-10-05 12:23:09 UTC
This attachment #140660 [details] got a lot better recently after:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=feec8e3c34e08b621098a17f1011dccd0b4f7f4c

author	Noel Grandin <noel.grandin@collabora.co.uk>	2019-11-12 16:00:55 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	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: 7.0.0.3 (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
Calc: CL

@Noel Grandin thanks for fixing this!