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
Created attachment 133452 [details] Example file
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
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)
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.
@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).
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
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
Adding Cc: to Justin Luth
cheap work-around, ignore keep with next on multipage tables: https://gerrit.libreoffice.org/56314 tdf#108000
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.
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.
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.
(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!!!