Steps to reproduce: 1. Open attachment 85819 [details] from bug 69351 with 'time OOO_EXIT_POST_STARTUP=1 instdir/program/soffice' it takes real 0m26,456s user 0m25,472s sys 0m0,426s in Version: 7.0.0.0.alpha0+ Build ID: fd1cd5522283f279a01d6d673f676a1346e9358b CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded while it takes real 0m7,497s user 0m6,986s sys 0m0,414s in Version: 6.2.0.0.alpha1+ Build ID: a20a2d7e0d28658f2d9089da076961a599833a28 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded thus, it's 3.5 times slower in master than in the past
Regression introduced by: author Miklos Vajna <vmiklos@collabora.com> 2019-09-30 21:36:56 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2019-10-01 19:47:39 +0200 commit d8371cdfd092c6426c01aae130ea4eaa6d627a6f (patch) tree 76d7fe03898138366a79d0ba8501bf4caaa10946 parent 000849f1cccba60c129c0c4cd8b66a29dcec2269 (diff) tdf#127446 vcl image lazy-load: fix custom size handling of metafiles Bisected with: bibisect-linux64-6.3 Adding Cc: to Miklos Vajna
Performance is one thing, but was the fast import result correct in 6.2? :-)
Created attachment 158893 [details] Before vs After the mentioned commit
At first glance, I don't see any difference before and after the mentioned commit
OK thanks, then we probably just don't hit the lazy-load path anymore and it needs tracking down why.
Created attachment 158900 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
Numbers from my machine: - >4 sec on 6.0 - <2 sec after acb803b730f2c6bd82e39beab58949ec14f85eb0 (but the result is incorrect in general) - >4 sec after d8371cdfd092c6426c01aae130ea4eaa6d627a6f (now that the result is correct) See bug 125591 and bug 127446 for cases where the fast result was not correct. I'll look at this and try to fix the performance problem while maintaining correctness, just noting that correct & fast was never the case at the same time, so this is not really a regression.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/952cc68929f863784c6b01c9dc071494892877d1 tdf#131496 vcl image lazy load: speed up vector images with custom pref size It will be available in 7.0.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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/983a92f697fc6399ad52dd1e757a88e8736bfdf2 tdf#131496 vcl image lazy load: speed up vector images with custom pref size It will be available in 6.4.4. 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.
Verified in Version: 7.0.0.0.alpha1+ Build ID: 8209c2569f5726f9ed29f75d30efdccb94f98fe5 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded it takes real 0m9,904s user 0m9,062s sys 0m0,416s @Miklos, thanks for fixing this issue!