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: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
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: 2022-12-23 03:36 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
slow-tiny.odt (37.45 KB, application/vnd.oasis.opendocument.text)
2019-05-08 09:42 UTC, Aleksei Nikiforov
Details
slow-medium.odt (69.51 KB, application/vnd.oasis.opendocument.text)
2019-05-08 09:43 UTC, Aleksei Nikiforov
Details
slow-large.odt (234.79 KB, application/vnd.oasis.opendocument.text)
2019-05-08 09:44 UTC, Aleksei Nikiforov
Details
perf flamegraph (1.36 MB, image/svg+xml)
2019-05-08 15:51 UTC, Julien Nabet
Details
slow-large-v2.odt (90.83 KB, application/vnd.oasis.opendocument.text)
2020-03-12 12:26 UTC, Aleksei Nikiforov
Details
perf flamegraph (303.28 KB, application/x-bzip)
2020-03-12 19:29 UTC, Julien Nabet
Details

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.

Version: 6.3.0.0.alpha0+
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]
slow-tiny.odt

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]
slow-medium.odt

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]
slow-large.odt

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 Comment hidden (obsolete)
Comment 5 Telesto 2019-05-08 14:26:06 UTC
Repro with
Version: 6.3.0.0.alpha0+
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
Versie: 4.4.7.2 
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 5.2.3.1 but hangs with LO 5.3.7.2.
Comment 8 Julien Nabet 2019-05-14 12:06:20 UTC Comment hidden (obsolete)
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)

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

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 Comment hidden (obsolete)
Comment 11 Aleksei Nikiforov 2020-03-12 07:23:23 UTC Comment hidden (obsolete)
Comment 12 Julien Nabet 2020-03-12 07:40:29 UTC Comment hidden (obsolete)
Comment 13 Mike Kaganski 2020-03-12 07:43:24 UTC
An idea would be to add a flag to the follow row frame indicating that it should not look back for the total row height before when the current height is greater than minimal ... or even not the flag, but simply the "previous height" to avoid looking back at all?
Comment 14 Aleksei Nikiforov 2020-03-12 12:26:55 UTC
Created attachment 158650 [details]
slow-large-v2.odt

(In reply to Julien Nabet from comment #12)
> You can retest the bug with LO 6.4.1 but no info since there was no comment.
I've built from sources and tried following version:

Version: 6.4.2.1
Build ID: c92dba0b4728c0ec26c4b83e2c0fbf3284425375
CPU threads: 12; OS: Linux 5.5; UI render: default; VCL: kf5; 
Locale: en-US (C); UI-Language: en-US
Calc: threaded

LO opens example files pretty fast, even larger ones. But on large examle even while it doesn't hangs for long time after opening file anymore, it still hangs for a bit and LO works pretty slow, constantly consuming 100% CPU according to 'top'.

I've tried replacing every word 'text' with phrase 'longer string with some spaces' to see if it'd make LO work slower. Not sure about result, I guess it might work a bit slower. I'm attaching resulting file.

(In reply to Mike Kaganski from comment #13)
> An idea would be to add a flag to the follow row frame indicating that it
> should not look back for the total row height before when the current height
> is greater than minimal ... or even not the flag, but simply the "previous
> height" to avoid looking back at all?
Caching results of size and position calculations might help. But in that case events affecting either size of position should invalidate such caches at least partially.
Comment 15 Julien Nabet 2020-03-12 13:15:56 UTC Comment hidden (obsolete)
Comment 16 Julien Nabet 2020-03-12 19:29:41 UTC
Created attachment 158658 [details]
perf flamegraph

Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
Comment 17 mattia.b89 2020-06-07 19:57:19 UTC
issue seems gone for me (tried with latest file attached here)

Arch Linux w/ libreoffice-fresh 6.4.4-1
Comment 18 Aleksei Nikiforov 2020-08-26 11:37:32 UTC
While Libreoffice no longer hangs after opening example file like it previously did, I'm still able to make it hang. Not sure if it's same issue resurfacing or some other issue.

For example, I'm opening previously attached "slow-large.odt" file, scroll to last page, click somewhere in the middle of table on that page, putting cursor there, and after that I press and hold "arrow up" key, effectively moving cursor few pages up while holding it. For example, I go from page 35 to page 30 via holding "arrow up" key. After that I release "arrow up" key and hold "arrow down" key and move back to page 35. Sometimes it hangs just for a moment when I'm doing this, other times it hangs for minutes, but sometimes it takes few times to move few pages up and down until any freeze happens.

About Libreoffice:
Version: 6.4.5.2
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-US (C); UI-Language: en-US
Calc: threaded
Comment 19 Telesto 2021-06-10 19:37:41 UTC
Still present
Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 3b57ebb445df8a2bc3d916ea79f8af45e20e4e62
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 20 Buovjaga 2022-04-13 16:56:25 UTC
(In reply to Aleksei Nikiforov from comment #18)
> While Libreoffice no longer hangs after opening example file like it
> previously did, I'm still able to make it hang. Not sure if it's same issue
> resurfacing or some other issue.
> 
> For example, I'm opening previously attached "slow-large.odt" file, scroll
> to last page, click somewhere in the middle of table on that page, putting
> cursor there, and after that I press and hold "arrow up" key, effectively
> moving cursor few pages up while holding it. For example, I go from page 35
> to page 30 via holding "arrow up" key. After that I release "arrow up" key
> and hold "arrow down" key and move back to page 35. Sometimes it hangs just
> for a moment when I'm doing this, other times it hangs for minutes, but
> sometimes it takes few times to move few pages up and down until any freeze
> happens.

I can't repro. Can you test with 7.4?

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 2f2df626117380427d2e5e8417316f52823f1e6f
CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Comment 21 Roman Kuznetsov 2022-05-25 10:05:49 UTC
Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: b6266207b55a7633dc82b02142215757512adfb7
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded

Opens fast and you can work with the document without any delay after opening at once.

Aleksei, please retest it
Comment 22 QA Administrators 2022-11-22 03:35:36 UTC Comment hidden (obsolete)
Comment 23 QA Administrators 2022-12-23 03:36:46 UTC
Dear Aleksei Nikiforov,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp