Description: FILEOPEN RTF: Time opening RTF with a very large page splitting table increased with around 30 seconds (since 5.3 with NEW layout engine) Steps to Reproduce: 1. Open the attached file and wait until CPU usage drops back to /- 0% Actual Results: 23 seconds with 4.4.7.2 (it still processing a while after opening, slower timers. but I would expect it to be around 30 seconds; not 40 40 seconds with 5.3 old layout engine 65 seconds with 7.1 Expected Results: 30-35 seconds maybe? Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: d851a02df57ab378ed0cc6d9362516de09c3279c 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
Created attachment 163099 [details] Example file
it takes real 2m15,178s user 2m13,065s sys 0m1,827s in Version: 7.1.0.0.alpha0+ Build ID: 32090b018d9ff81659a4c9ed41c64109ebebe4fc CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
*** Bug 134852 has been marked as a duplicate of this bug. ***
Telesto: would you like to re-test? After https://git.libreoffice.org/core/commit/7678e7ed88007061c3469db3b28b0e91acea7ed6 and https://git.libreoffice.org/core/commit/2cb75eb504e3fedb9c93bbfee3609021f583f849 I think this might be acceptable. See some results in bug 148911
Still slow, but Word complains about the file being broken Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 00e43c14558fa4d0369820fa3d2cd7b987e61377 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (nl_NL); UI: en-GB Calc: CL