1. Download attachment 137113 [details] 2. time OOO_EXIT_POST_STARTUP=1 instdir/program/soffice /path/to/10401.xls Before commit ae7807c889c19145f89cec40afac82eee191837c (ITEM: No longer register Items at Pool), I get real 0m10,371s user 0m10,020s sys 0m0,290s After it, I get real 1m44,354s user 1m41,407s sys 0m0,569s Bibisected with linux-64-24.8
Reproducible with Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Several minutes with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bff48f885e3aad560776a42e451a735ed6c72c57 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Created attachment 195099 [details] Perf flamegraph Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 85fd526fc681a994415bb422090d1d23aa7d54f6 CPU threads: 8; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
So there is a pre-existing weirdness in our data-model. Which is that our gradient objects insist on all having a unique name. Why our gradient objects need a name is beyond me - they should just be another property of the SvxShape. And this document exercises this weirdness in a rather extreme way because it contains thousands of shapes, with every shape having a gradient. Surely SvxShape should contain an unnamed gradient property XFillGradientPoolItem object, then we can share/pool those objects easily?
Opening is also slow in MS Office 365. It takes 20second for me.
@Noel: It's because it uses the surrogate hack/mechanism: The import (also the normal draw/impress one) creates the needed Items and puts them in a ItemSet (or PoolItemholder). Then the UNO API is used to *set* the e.g. gradient by *transfering* the name. The impl of the UNO API then uses the surrogates to 'search' that instance and set as value... sigh... Of course the imports could also just set the gradient, but that is not what happens. Somehow this started with Graphics being transferred by a created UUID, then that was copied, etc... For that reasons the names have to be unique -> not only for one doc in the office, but for the whole office globally. If we would change that to what *should* happen - setting the gradients and other NameOrIndex Item-types - names would still have to be unique for the document model, lots of UI stuff uses that... HTH! Not sure though how to fix that, I do not want to 'speedup' the hack, but sometimes...
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/be5fad6d0755e3d1e7ab5c9d4bfda8248b4e51d2 tdf#161875 buffer NameOrIndex Items for fast Surrogates It will be available in 25.2.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.
Thanks, now it's real 0m11,937s user 0m11,789s sys 0m0,193s so can be closed as fixed. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7628892b04d1a1ed47d6d6c355940f9915dcd99 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded