Description: Very long time works autofilter in XLSX file with 1500 comments in cells. About 30 sec in Version: 6.2.0.0.alpha0+ (x64) Build ID: d0425778eef7ea20ccc19834c07d0b265f58baf0 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-08_03:06:53 Locale: ru-RU (ru_RU); Calc: CL In ODS file with same content, autofilter works very fast Steps to Reproduce: 1. Open XSLX file from attach and try filter content with autofilter in columnt A 2. 3. Actual Results: Very long time works autofilter in XLSX file with 1500 comments in cells Expected Results: autofilter in XLSX file with 1500 comments in cells works very fast, as in ODS with same content Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 144598 [details] Example XLSX file with 1500 comments
Created attachment 144599 [details] Example ODS file with 1500 comments
Repro Version: 6.2.0.0.alpha0+ (x64) Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04 Locale: es-ES (es_ES); Calc: CL
Undoing the filtering makes LibreOffice to hang...
it's much faster in gen than in gtk3 or gtk...
Also reproduced in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Ilhan, may be you are interested of this bug
in Версия: 6.2.0.0.beta1 ID сборки: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 Потоков ЦП: 4; ОС:Windows 6.1; Отрисовка ИП: по умолчанию; VCL: win; Локаль: ru-RU (ru_RU); UI-Language: ru-RU Calc: threaded It takes only 7 sec for autofilter's work Can to matter status of OpenGL?
3 sec in Version: 6.3.0.0.alpha0+ Build ID: cec3fe24dd4569bf04b13e0284823bad129dbb86 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-02-02_03:18:07 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
(In reply to Roman Kuznetsov from comment #9) > 3 sec in > > Version: 6.3.0.0.alpha0+ > Build ID: cec3fe24dd4569bf04b13e0284823bad129dbb86 > CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; > TinderBox: Win-x86@42, Branch:master, Time: 2019-02-02_03:18:07 > Locale: ru-RU (ru_RU); UI-Language: en-US > Calc: threaded Compare to the initial report, it's 1/10 of the time time. I would say it's RESOLVED WORKSFORME
Created attachment 151039 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, it seems to hang. I retrieved a bt at random during loading.
On pc Debian x86-64 with master sources updated today + enable-symbols, I don't reproduce this. I still reproduce the slowness with enable-dbgutil but perhaps it's not relevant. I think all Noel's optimizations may have helped here. Roman: could you give a try to a recent daily master build?
(In reply to Julien Nabet from comment #12) > On pc Debian x86-64 with master sources updated today + enable-symbols, I > don't reproduce this. > > I still reproduce the slowness with enable-dbgutil but perhaps it's not > relevant. > > I think all Noel's optimizations may have helped here. > Roman: could you give a try to a recent daily master build? I got 6 sec in Version: 6.4.0.0.alpha0+ (x64) Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded It is still slow I think
Created attachment 152072 [details] Flamegraph Flamegraph done on pc Debian x86-64 with master sources updated yesterday + enable-symbols
Around 6 seconds in Version: 6.4.0.0.alpha0+ Build ID: ec905d131374f0860bac77c52873eed984b1966f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded as said in comment 4, it hangs undoing the filtering. I'll create another bugreport
Adjusting Summary. Very long time doesn't seems to be accurate. it takes 6 seconds... it doesn't seem like very long time to me...
(In reply to Xisco Faulí from comment #16) > Adjusting Summary. Very long time doesn't seems to be accurate. it takes 6 > seconds... it doesn't seem like very long time to me... takes ~7 sec in Version: 6.5.0.0.alpha0+ (x64) Build ID: b6295e4a1b7735c148174f44f6d28221f4f52302 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
There is a delay when filtering in the first attachment (i.e. the XLSX document, attachment 144598 [details]), but the second one in instant, with the latest master builds which includes the improvements in autofilter (see bug 133835). @Luboš Luňák and @Noel Grandin, I think you may also be interested in this one?
Created attachment 176520 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today (b18c2a0024c6d33cdf142ed2adf0d127483411e8) with gen rendering on xlsx file. Accessing filter is instant, then I deselected all (instant too) and finally chose 1 value (some seconds)
Still 6 sec delay in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1be170d0629cf761f0ee4173007a3c021966546e CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL I still use an old CPU here - Intel Core 2 Quad 9450
Finally it was fixed I checked in my own build Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d635e73308dc6fcea9897855b5167be09f52f840 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Filter took less than 1 sec Closed as WFM (I think it was Caolan's patch https://gerrit.libreoffice.org/c/core/+/155569, but I won't check it)