Description: Slowly work of autofilter in 6.2 in comparison by 6.1 Version: 6.2.0.1 Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded Steps to Reproduce: 1. Open file from attach 2. Try to use autofilter in column A or B 3. Comparise behaviour and speed of work with 6.1 Actual Results: Slowly work of autofilter in 6.2 in comparison by 6.1 Expected Results: work of autofilter in 6.2 has same speed as in 6.1 Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 147830 [details] Example with Autofilter
It's far to slow Version: 6.3.0.0.alpha0+ Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-12-06_23:55:16 Locale: en-US (nl_NL); UI-Language: en-US Calc: CL
$ git bisect bad 6a4603a88189d5dbbf6b7ba0df93d5dff826d7db is the first bad commit commit 6a4603a88189d5dbbf6b7ba0df93d5dff826d7db Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Aug 16 00:19:17 2018 -0700 source c135f51b050dfa7ef095fe8a5b73cde37219a8dd https://gerrit.libreoffice.org/#/c/59134/ CC: Noel Grandin
(In reply to Roman Kuznetsov from comment #3) > $ git bisect bad > 6a4603a88189d5dbbf6b7ba0df93d5dff826d7db is the first bad commit > commit 6a4603a88189d5dbbf6b7ba0df93d5dff826d7db > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Thu Aug 16 00:19:17 2018 -0700 > > source c135f51b050dfa7ef095fe8a5b73cde37219a8dd > > https://gerrit.libreoffice.org/#/c/59134/ > > CC: Noel Grandin ohohoho, I'm sorry people, I bisected another bug=(((
(In reply to Roman Kuznetsov from comment #0) > 2. Try to use autofilter in column A or B there is the difference between 6.2 and 6.1 only for column B for me Autofilter for column A works badly in 6.1 too problem of speed is in hyperlinks in cells
(In reply to Roman Kuznetsov from comment #5) > Autofilter for column A works badly in 6.1 too > problem of speed is in hyperlinks in cells It's a bug, IMHO (separate one of course; please create additional report :-). No issue with column A in Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 Repro with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Created attachment 148681 [details] bibisect, tail of terminal output Working on debian-buster in bibisect-lilnux-64-6.2 repository, I find: commit s-h -------- -------- good 7433d2fb df652aa7 bad 8cfe6975 c8a739a2 for which the commit message is: commit c8a739a2c84f45f878d2ae75eaf16a2f814d1c6e Author: Serge Krot <Serge.Krot@cib.de> Date: Thu Jun 7 18:02:50 2018 +0200 tdf#117276 filter reset: check complete data range selected Change-Id: I5cbd515753ad606f55cedaa7023ffe88671f4702 Reviewed-on: https://gerrit.libreoffice.org/55436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de> Watching CPU time used, at each probe I deselected the first six values shown in the autofilter dialog for columnn B and then selected those six values again. The CPU times for each deselection were about 7 seconds (6.48 to 7.15). The CPU times for subsequent selection fell into to groups: less than one second (0.05 to 0.11) I deemed good, about 7 seconds (6.64 to 6.94) I deemed bad. I am adding Serge Krot to cc. I am removing keyword bibisectRequest, and adding bibiseced and bisected.
Hi Roman, Could you please check if this issue is fixed after https://git.libreoffice.org/core/+/fb3c3216ba1a6fc978176eebcef0cab4599a39e7%5E%21 for bug 122260
don't repro it 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 FIXED, but please backported it into 6.2
(In reply to Roman Kuznetsov from comment #9) > FIXED, but please backported it into 6.2 See https://git.libreoffice.org/core/+/eb2d8e088fef630bd16fea3317a6ac74ebd2f3ce%5E%21
(In reply to Roman Kuznetsov from comment #9) > FIXED, but please backported it into 6.2 Setting to VERIFIED