Bug 108000 - FILEOPEN DOC: File is opening very slow
Summary: FILEOPEN DOC: File is opening very slow
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All All
: medium major
Assignee: Justin L
URL:
Whiteboard: target:6.2.0 target:6.1.0.1
Keywords: bibisected, bisected, filter:doc, perf, regression
Depends on:
Blocks: DOC
  Show dependency treegraph
 
Reported: 2017-05-22 15:55 UTC by Telesto
Modified: 2020-05-21 08:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (6.47 MB, application/x-zip-compressed)
2017-05-22 15:56 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-05-22 15:55:41 UTC
Description:
This report closely related to bug 103097. I have exported the attachment 127935 [details] to DOC with LibO5400b1 without any issue. I can open the file perfectly fine in Word. However reopening the file in LibO is problem. 

Steps to Reproduce:
1. Try to open the attached file

Actual Results:  
File won't open (or very slowly)

Expected Results:
File should open quite fast


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: 5.5.0.0.alpha0+
Build ID: d57e6cd9dcc96112994ca2b14ac45896e86b26e5
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-05-18_22:43:07
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Telesto 2017-05-22 15:56:05 UTC
Created attachment 133452 [details]
Example file
Comment 2 Xisco Faulí 2017-05-23 09:09:07 UTC
Confirmed in

Version: 5.4.0.0.alpha1+
Build ID: 74d2e606fd3605fe0a585f596eaa215ae4e20d18
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: en-US (ca_ES.UTF-8); Calc: group

After 10 minutes I killed it:

time OOO_EXIT_POST_STARTUP=1 instdir/program/soffice /home/xisco/Baixades/Kalenborn\ Geschichte\ Tabelle.doc 

real	10m24.898s
user	10m24.124s
sys	0m0.296s
Comment 3 Xisco Faulí 2017-05-23 10:14:51 UTC
Also reproduced in

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)
Comment 4 Terrence Enger 2017-05-24 11:25:44 UTC
I wonder if the versions reported to be slow are all dbgutil builds?
And then, is poor performance in a dbgutil build really a bug?

Working on debian-stretch 64-bit, I see that versions from the 50max
bibisect repository open the attachment in under 4 minutes CPU time,
while versions from the till51 and till52 dbgutil bibisect repos take
(when I allow them to run to "completion") 39 minutes CPU.  Between
the source hash 90e2dabb at the end of 50max and source hash 0db96acf
at the start of till51, there were only 50 commits to master.
Comment 5 Telesto 2017-05-24 12:40:52 UTC
@Terrence
The issue exists with normal builds to within the Lib5 branch

File opens within 45 seconds with:
Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: nl-NL (nl_NL)

However. The table are differently distributed (far more pages).
Comment 6 Xisco Faulí 2017-06-16 11:32:32 UTC
in

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

it takes

real	1m21.512s
user	1m12.128s
sys	0m0.424s
Comment 7 Buovjaga 2018-05-23 18:59:31 UTC
Bisected to https://cgit.freedesktop.org/libreoffice/core/commit/?id=0d127baed75929e744d5b6249f510012cfbc0e88

commit	0d127baed75929e744d5b6249f510012cfbc0e88 (patch)
tree	428628b43ebaa4fdb40e6077aac0964ae9e195b4
parent	57997db73725583a84dbac36bcc9c1b2829948f9 (diff)
tdf#91083 - .doc: emulate table keep-with-next paragraph
connect table with the following paragraph.  Move forward to a new page
together with the following paragraph if necessary.

Most of the added code allows the table to split if
all of the kept items do not fit on one page - allowing
the emulated table to match the layout of kept tables.

The only difference with .doc occurs when the table itself is larger
than one page.  In that case it ALWAYS starts a new page.  Although
it does not match .odt, it DOES match how MSWord handles that .doc.

Change-Id: Ic6f495c0dc5cd4e9f8029a8cec9e31b4fab4b20f
Reviewed-on: https://gerrit.libreoffice.org/20233

Same commit is blamed for bug 114908

Adding Justin to CC
Comment 8 Xisco Faulí 2018-06-05 19:11:54 UTC
Adding Cc: to Justin Luth
Comment 9 Justin L 2018-06-23 12:32:41 UTC
cheap work-around, ignore keep with next on multipage tables: https://gerrit.libreoffice.org/56314 tdf#108000
Comment 10 Justin L 2018-06-23 17:16:28 UTC
Interesting bibisect results:
Bibisect-50max master: real	1m0.335s
user	0m59.892s
sys	0m0.338s71s

Bibisect-51 dbg oldest: real	16m53.676s
user	16m42.772s
sys	0m0.471s[@

There is a day of overlap here.  bibisect51's oldest is one day older than  bibisect50, so the time difference must be based on something else. I'm guessing that it is because one is a debug build, and the other one isn't.
Comment 11 Commit Notification 2018-07-02 04:04:18 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fc90f7ea8034e9585486ea9cc3e55771aca85540

tdf#108000 sw layout: ignore emulated keep on large tables

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2018-07-03 15:46:32 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d96ba7a7df7d28558adaaf9b28026dd73855c3cb&h=libreoffice-6-1

tdf#108000 sw layout: ignore emulated keep on large tables

It will be available in 6.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Xisco Faulí 2018-07-04 12:12:39 UTC
(In reply to Xisco Faulí from comment #2)
> Confirmed in
> 
> Version: 5.4.0.0.alpha1+
> Build ID: 74d2e606fd3605fe0a585f596eaa215ae4e20d18
> CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
> Locale: en-US (ca_ES.UTF-8); Calc: group
> 
> After 10 minutes I killed it:
> 
> time OOO_EXIT_POST_STARTUP=1 instdir/program/soffice
> /home/xisco/Baixades/Kalenborn\ Geschichte\ Tabelle.doc 
> 
> real	10m24.898s
> user	10m24.124s
> sys	0m0.296s

It takes

real	1m11.609s
user	1m9.940s
sys	0m1.015s


in

Version: 6.2.0.0.alpha0+
Build ID: d05b7b32d9ecb6fcb4a268eb68cdcee09bafa6dd
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

Setting as VERIFIED!!

@Justin, thanks for fixing this!!!