Bug 148911 - FILEOPEN RTF Opening time of an RTF with a very large page splitting table has grown a lot
Summary: FILEOPEN RTF Opening time of an RTF with a very large page splitting table ha...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: RTF
  Show dependency treegraph
 
Reported: 2022-05-03 14:40 UTC by Buovjaga
Modified: 2022-05-04 17:30 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By: Luboš Luňák


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Buovjaga 2022-05-03 14:40:17 UTC
1. In a terminal, say export OOO_EXIT_POST_STARTUP=1
(and don't forget to close the terminal when you're done so you don't get confused later)
2. Using the time command, open attachment 163099 [details] from bug 134854

Good result:
real    0m43,072s
user    0m42,401s
sys     0m0,400s

Regressed result:
real    2m44,143s
user    2m39,669s
sys     0m1,700s

Bibisected with linux-64-7.4 to:
https://git.libreoffice.org/core/commit/8e6ab6502278702499e7468404d1010069176578
better cache size limit for SalLayoutGlyphsCache
Comment 1 Luboš Luňák 2022-05-03 17:54:57 UTC
I cannot reproduce with current master, and it also doesn't make much sense to me that commit would cause this. What is your exact version?
Comment 2 Buovjaga 2022-05-03 18:06:59 UTC
Sorry, I didn't check with different VCL UIs.

With gen, I get
real    0m14,552s
user    0m14,023s
sys     0m0,219s

With gtk3, I get
real    0m36,598s
user    0m36,248s
sys     0m0,186s

So the problem is only with kf5.
Comment 3 QA Administrators 2022-05-04 03:51:15 UTC Comment hidden (obsolete)
Comment 4 Luboš Luňák 2022-05-04 04:14:41 UTC
Apparently there is a scheduling difference (or something) between different VCL backends, so kf5 with OOO_EXIT_POST_STARTUP exits only after complete layout while others already before. I expect that if you measure the time until you can move the cursor in the document the time will be about the same.

And I'd still like to know how recent your build is.
Comment 5 Buovjaga 2022-05-04 05:18:07 UTC
(In reply to Luboš Luňák from comment #4)
> Apparently there is a scheduling difference (or something) between different
> VCL backends, so kf5 with OOO_EXIT_POST_STARTUP exits only after complete
> layout while others already before. I expect that if you measure the time
> until you can move the cursor in the document the time will be about the
> same.
> 
> And I'd still like to know how recent your build is.

Measured with a stopwatch, the time the cursor starts working is the same as the terminal-measured time. I tested with kf5 yesterday and now confirmed with gen.

Last commit in 7.4 repo:
commit 271a805c92aa869d5966f06d6fac0c12c921f0db (HEAD -> master, origin/master, origin/HEAD)
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon May 2 20:14:22 2022 +0200

    source sha:75fe4051320ef9b1f4323fa958e8df3db2066882
    
    source sha:75fe4051320ef9b1f4323fa958e8df3db2066882
Comment 6 Commit Notification 2022-05-04 06:44:38 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2cb75eb504e3fedb9c93bbfee3609021f583f849

lay out entire strings in SalLayoutGlyphsCache more often (tdf#148911)

It will be available in 7.4.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 7 Luboš Luňák 2022-05-04 06:45:17 UTC
Please try a more recent build.
Comment 8 Buovjaga 2022-05-04 16:57:25 UTC
I built with my non-debug work tree and it seems you nailed it.

kf5 gives this now:
real    0m31,546s
user    0m31,198s
sys     0m0,150s

gen:
real    0m9,044s
user    0m8,533s
sys     0m0,187s

gtk3:
real    0m23,927s
user    0m23,690s
sys     0m0,143s

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 6ebf46e332facfae5fd6027ec667ccd5993dd493
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