Description: Opening XLSX with multiline text is slow 30 seconds on master. Previously 8 seconds Steps to Reproduce: 1. Open the attached file. XLSX export from attachment 151324 [details] Actual Results: Takes 30 seconds to open Expected Results: Somewhere around 8 seconds Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded and in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7afd11f8e476884662c18db85445752cc030b2e2 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded Fine with Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 35f19e5cb93ce218787904e99c2bedfd40e725cc CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Created attachment 200786 [details] Sample
Unable to reproduce. Time to open was ~9 seconds with both versions tested. Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5 CPU threads: 22; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
About 20 seconds with Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-GB Calc: CL threaded But I am not sure that a master dev is suitable for such comparisons.
Thank you for reporting the bug. I can confirm a significant delay in opening under the setups listed below: 24 seconds for Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 2; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded 26 seconds for Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
13 seconds with Version: 25.2.3.1 (X86_64) / LibreOffice Community Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded 17/18 seconds with Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0d8ebf963a294f50efc0a36bb45059e82ddd5118 CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Bisected to 0b2a90ff910ccd9dea6deebe5ddee58e60d2fb5f is the first bad commit commit 0b2a90ff910ccd9dea6deebe5ddee58e60d2fb5f Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Jul 16 06:31:37 2023 -0700 source d15c4caabaa21e0efe3a08ffbe145390e802bab9 source d15c4caabaa21e0efe3a08ffbe145390e802bab9 instdir/program/scfiltlo.dll | Bin 4911104 -> 4911104 bytes instdir/program/sclo.dll | Bin 17253376 -> 17254400 bytes instdir/program/scuilo.dll | Bin 855552 -> 855552 bytes instdir/program/setup.ini | 2 +- instdir/program/vbaobjlo.dll | Bin 1725952 -> 1725952 bytes instdir/program/version.ini | 2 +- 6 files changed, 2 insertions(+), 2 deletions(-)
(In reply to Telesto from comment #6) > Bisected to 0b2a90ff910ccd9dea6deebe5ddee58e60d2fb5f is the first bad commit > commit 0b2a90ff910ccd9dea6deebe5ddee58e60d2fb5f > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Sun Jul 16 06:31:37 2023 -0700 > > source d15c4caabaa21e0efe3a08ffbe145390e802bab9 The commit is about improving the accuracy of import. Notice what the messages says: I'm not sure I'm ready for the regression hate that would come from the inevitable performance implications. With 25.2.3 I get real 0m17,374s user 0m16,587s sys 0m0,384s With master I get real 0m14,811s user 0m14,125s sys 0m0,373s Arch Linux 64-bit Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 2ad7444110dad0869dcca711c4db9367fef85061 CPU threads: 8; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 25 May 2025
(In reply to Buovjaga from comment #7) I think we have make a distinction between the performance degradation to be expected from optimal row height recalculation and the performance degradation encountered So it's started with "recalc optimal row height on import" commit for some reason, but it's not related to the actual recalculation. At least if the status bar being representative for the inner workings: It has become slow on the file import part (import filter/ fast parser end). The Adapt Row Height is only flashing for moment. Most of the time I'm complaining about is spend 'waiting' on NtUserGetMessage (5 seconds/ 33% of the profile) accordingly to VerySleepy Profile. So it might even be Windows specific. NtUserGetMessage GetMessageW create_SalInstance create_SalInstance Application::Execute com_sun_star_comp_oox_xls_FormulaParser_get_implementation com_sun_star_comp_oox_xls_FormulaParser_get_implementation sax_fastparser::FastAttributeList::operator=