Bug 166568 - Opening XLSX with multiline text is slow 30 seconds on master. Previously 8 seconds
Summary: Opening XLSX with multiline text is slow 30 seconds on master. Previously 8 s...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf
Depends on:
Blocks: Regressions-row-height
  Show dependency treegraph
 
Reported: 2025-05-13 19:38 UTC by Telesto
Modified: 2025-05-26 11:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample (130.03 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2025-05-13 19:38 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2025-05-13 19:38:23 UTC
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
Comment 1 Telesto 2025-05-13 19:38:35 UTC
Created attachment 200786 [details]
Sample
Comment 2 Andrew Kopf 2025-05-13 21:26:50 UTC
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
Comment 3 m_a_riosv 2025-05-14 00:17:13 UTC
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.
Comment 4 Jeremy Norvell 2025-05-14 01:04:42 UTC
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
Comment 5 BogdanB 2025-05-14 04:36:03 UTC
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
Comment 6 Telesto 2025-05-15 19:34:18 UTC
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(-)
Comment 7 Buovjaga 2025-05-25 09:30:25 UTC
(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
Comment 8 Telesto 2025-05-25 11:00:39 UTC
(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=