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
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?
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.
[Automated Action] NeedInfo-To-Unconfirmed
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.
(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 75fe4051320ef9b1f4323fa958e8df3db2066882 source 75fe4051320ef9b1f4323fa958e8df3db2066882
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.
Please try a more recent build.
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