Bug Hunting Session
Bug 125171 - Writer FILEOPEN, FORMATTING, VIEWING: very slow, hanging when opening files with complex tables
Summary: Writer FILEOPEN, FORMATTING, VIEWING: very slow, hanging when opening files w...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: Writer-Tables CPU-AT-100%
  Show dependency treegraph
Reported: 2019-05-08 09:41 UTC by Aleksei Nikiforov
Modified: 2019-05-20 08:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

slow-tiny.odt (37.45 KB, application/vnd.oasis.opendocument.text)
2019-05-08 09:42 UTC, Aleksei Nikiforov
slow-medium.odt (69.51 KB, application/vnd.oasis.opendocument.text)
2019-05-08 09:43 UTC, Aleksei Nikiforov
slow-large.odt (234.79 KB, application/vnd.oasis.opendocument.text)
2019-05-08 09:44 UTC, Aleksei Nikiforov
perf flamegraph (1.36 MB, image/svg+xml)
2019-05-08 15:51 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksei Nikiforov 2019-05-08 09:41:29 UTC
When opening some files created by MSO, Libreoffice shows a page for a few moments and after that hangs for a while, and after that initial hang starts showing file normally, although it may work slow when editing such file. Exact hangup time depends on hardware, used interface type and file, but it may last from approximately 30 seconds to dozens of minutes.

To reproduce issue I've created an MSO document and copied a table with a few columns and a lot of rows, and for first column I've merged approximately every 3 rows, after that I've saved document as ODT. Opening such file reproduces issue for me.

Build ID: ac854a4ccfcdcd75e93fbf629b6191821099b0a3
CPU threads: 12; OS: Linux 5.0; UI render: default; VCL: kde5; 
Locale: en-US (C); UI-Language: en-US
Calc: threaded
Comment 1 Aleksei Nikiforov 2019-05-08 09:42:42 UTC
Created attachment 151234 [details]

A file with 5 pages of table rows. Hangs for approximately 30-60 seconds for me.
Comment 2 Aleksei Nikiforov 2019-05-08 09:43:48 UTC
Created attachment 151235 [details]

File with 10 pages of table rows, hangs for approximately 2-5 minutes for me.
Comment 3 Aleksei Nikiforov 2019-05-08 09:44:56 UTC
Created attachment 151236 [details]

File with over 20 pages of table rows, hangs for more than 10 minutes for me.
Comment 4 Aleksei Nikiforov 2019-05-08 09:47:43 UTC
I've tested it with releases, and, and it happens for all of them. I didn't test earlier releases.
Comment 5 Telesto 2019-05-08 14:26:06 UTC
Repro with
Build ID: 91b2239783dc716bd71ce7962bfd7e341dfe4175
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-05-08_09:49:32
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded

nearly instant opening with
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 6 Julien Nabet 2019-05-08 15:51:49 UTC
Created attachment 151248 [details]
perf flamegraph

On pc Debian x86-64 with master sources updated today and enable-symbols (not enable-dbgutil), the first file doesn't even open after several minutes (Ryzen 2600 + RAM 32 Go)
Comment 7 Aleksei Nikiforov 2019-05-14 11:24:51 UTC
It looks like it works fine with LO but hangs with LO
Comment 8 Julien Nabet 2019-05-14 12:06:20 UTC
Thank you Aleksei for these info.
Let's put earliest version to then.
Comment 9 Aleksei Nikiforov 2019-05-20 08:39:27 UTC
I've ran bisect and this is my result:

8a800eea613c0f5ad3302136766791dc58880fb3 is the first bad commit
tdf#104425 sw: split rows w/large min height (fix layout loop)


I've confirmed that if I revert this change on current master (there are some revert conflicts which needed to be resolved), attached files are opened almost instantly now, while it took minutes and tens of minutes before.

I guess reverting this change for LO might be not an option, but at least adding a configuration option allowing to choose between correct table formatting and fast table formatting might be a good idea, unless performance can be fixed for current implementation. I didn't look into performance issue in this change yet.
Comment 10 Aleksei Nikiforov 2019-05-20 08:51:27 UTC
Adding Cc: to Mike Kaganski