Created attachment 203566 [details] Sheet to benchmark countifs() formula The attached Excel sheet calculates the time taken for countifs() formula on a large amount of data. In Calc version 7.4.1.2, it takes only 20 seconds on Core i7-4770 to complete. In the latest version 25.8.2.2, it does not finish calculation even after two minutes. I did not wait for it to complete as it seems it may take a very long time.
Hard recalculation is instantaneous (macros disabled) with Version: 25.8.3.1 (X86_64) Build ID: 52ad9dd1c984050a9fb6932dbfb16e86a49e9758 CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded Please test in safe mode, Menu/Help/Restart in Safe Mode Please paste here the information on Menu/Help/About LibreOffice (There is an icon to copy)
Version: 7.4.1.2 (x86) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 8; OS: Windows 10.0 Build 26200; UI render: Skia/Raster; VCL: win Locale: en-US (en_AE); UI: en-US Calc: CL ^^^ Working fine Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-AE (en_AE); UI: en-US Calc: CL threaded ^^^ Performing very slowly in the particular scenario being tested by the attached sheet. I used the portable version 7.4.1.2 to avoid having to install the old version side by side. The non-portable version is similar in behavior on a different PC (Core i5-2400 and takes 25 seconds to finish). Let me just test with macros disabled on 25.8.2.2 and report back.
Tried it in the latest version in safe mode with macros disabled. Version: 25.8.3.1 (X86_64) Build ID: 52ad9dd1c984050a9fb6932dbfb16e86a49e9758 CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: default; VCL: win Locale: en-AE (en_AE); UI: en-US Calc: threaded Calculation did not complete in more than 60 seconds whereas it completes in 20 seconds in version 7.4.1.2. Steps to reproduce the issue: 1. Copy formula in cell H2. 2. Paste formula from cell H3 to cell H187278.
When I press Benchmark button, LibreOffice crash after long time of running (Fatal exception: Signal 11) I've commented line in macro " Application.CutCopyMode = False", which is not supported in LibreOffice. When I copy paste H2 to cells H3:H187278, I've stopped the LibreOffice after ten minutes. My HW is weak and old. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2595f031fa93c1eb89fb4dce6f337de9be813e15 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.10 Calc: threaded
No issue with version 7.4.1.2 and benchmark completes successfully without any error in 27 seconds. Version: 7.4.1.2 (x64) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Added a screenshot of the slowest PC I have.
Created attachment 203582 [details] Core i5-2400 Windows 7 completing the benchmark successfully
Created attachment 203691 [details] Crash log on Macbook Air M1 Apple Silicon Running the benchmark on M1 Macbook Air led to crash with version 24.8.2.1 and log is attached. Benchmark completed in a blazing fast 8 seconds with version 7.4.1.2
Hello Team. Any update?
bibisected with linux-64-7.6 Disable the macros, open the file, and follow the steps in comment 3. It either ends in about 15 seconds or takes more than a minute to finish. commit 9a555d79b3b00793edf1d51a8a7c76b723cc436d author Eike Rathke Resolves: tdf#151958 Disable binary search on sorted cache for current releases *** adding CC: Eike Rathke Please, take a look? *** @adnanbaloch Eike is retired so I don't know if it will be fixed soon.
Of course there's a performance regression with that commit removing the binary search on sorted cache code path that produced wrong results. That is expected. Someone should fix the actual cause of bug 151958 for which that commit was a workaround. And no, that wouldn't be me.