Description: Very slow opening of a ODS with autofilter + conditional formatting Steps to Reproduce: 1. Open attachment 155912 [details] -> takes 35 minutes to open (bug 121386) Actual Results: 35 minutes opening time Expected Results: 5 minutes like 4.1 (in 4.1 it's iterating row count in 7.1 ScMatrix) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: a201ab6f47c2d5a7ba4c5f998b0aa231cae82010 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in 4.4.7.2 based on the very sleepy feedback (look "same" as in 7.1) but not in 4.1
it takes real 6m50,396s user 7m9,147s sys 0m6,759s in Version: 7.1.0.0.alpha0+ Build ID: 37d5cccceb9f02d60de326f5b1fc5098dc004739 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Don't think it's a regression
(In reply to Xisco Faulí from comment #1) > it takes > > real 6m50,396s > user 7m9,147s > sys 0m6,759s > > in > > Version: 7.1.0.0.alpha0+ > Build ID: 37d5cccceb9f02d60de326f5b1fc5098dc004739 > CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded > > Don't think it's a regression Or Windows vs Linux.. Will take a look this evening
First my lesson: Never trust numbers given by bug reporter.. Anyhow: with 7.1 (win): 5:20 with 4.4.7.2 (win): waited 9 minutes.. kill with 4.2 (win): 3:30 Now the quest: reducing the file to something which can be bibisected.. or the boring task of bibisected this using the file at hand.
Created attachment 162424 [details] flamegraph While recording the flamegraph, I killed LibreOffice after a while, since the document never finished to load
(In reply to Xisco Faulí from comment #4) > Created attachment 162424 [details] > flamegraph > > While recording the flamegraph, I killed LibreOffice after a while, since > the document never finished to load @Noel, I thought you might be interested in this performance issue
This file now opens within 1min on my master build as of today, after the improvements in autofilter speed, see bug 133835 and bug 136838. However, this bug may have been fixed long time ago, I am not sure. Now the slowness in this document seems to be in the calculation of array formula , not in autofilter. Telesto could you please test and confirm with a daily build tomorrow?
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bf74eb1d1623a51805f91a973bc9f726d14dd7a8 tdf#133996 speed up opening of ODS with autofilter + conditional formatting 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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/85a2c5c71e5be5cffd9d40c1dd19bd1e69eef2bf tdf#133996 speed up opening of ODS with autofilter + conditional formatting It will be available in 7.3.0.0.beta2. 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.
Revise status to Resolved Fixed as there is a commit.
I get the following times with LO 7.3.0.2 on Ubuntu 18.04.6: real 1m32.338s user 1m32.214s sys 0m1.013s With version: Version: 7.3.0.2 / LibreOffice Community Build ID: f1c9017ac60ecca268da7b1cf147b10e244b9b21 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I guess that's less than 5 minutes!