Description: Open file slightly slower & ctrl+a causes CPU to peak Steps to Reproduce: 1. Open the attached file (based on bug 88109) 2. Press CTRL+A -> And look at the CPU usage Actual Results: 25% CPU for 5/6 seconds Expected Results: Shouldn't be Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.beta1+ Build ID: c344de1b9985b6ca10b354e24151d0bdf92dc20e CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 161848 [details] Example file
Created attachment 161849 [details] Bibisect log # possible first bad commit: [d371fd0cdabdf23f89e7f7c578839ea9ef584578] source-hash-e1b14fa6557f0ded8b5149e28e00861b296dcb34 # possible first bad commit: [d0aa721aa6e5c22da0ea848e902eb98e4d5885f3] source-hash-347af397cafa97cfa7d5027f83fff784ca04a397 # possible first bad commit: [bc5b8053d8d6bdda5eb1a9c1c945a93317be64b9] source-hash-17b00767948f7add229ec589c06cd8c898032ffa # possible first bad commit: [4c05a6f754ec6d1841a04f0b43a73b12d549f139] source-hash-8728f8e8705cfb6875a315aef85ec6004604e702 # possible first bad commit: [6b5d730f8576dfa70d2ecd090e4e99ea926f8eca] source-hash-4a7a6b46c0dc779581f271b9e6c13c365eca7ab8 # possible first bad commit: [cb044da515b41ea546c86fd538345db9330df91c] source-hash-c0d5d26ad74cc7b6470d1e0c8951bee548c7ba17 # possible first bad commit: [204f1bdcec10bf68ac186378443bead79892c88f] source-hash-9ca4e6e1940a22cf82cc492da6a3ce0b3d8e0e80 # possible first bad commit: [7509b8a79aad61ca7492cc30303af8820a110cd5] source-hash-5b8ad54cc596a58da1f79937cc6709ce0799ac7f # possible first bad commit: [f77515fd5283b422312e39e1b13ed92e68c7de78] source-hash-6404567b0ad3dab20f39eb93114a30f0b2016f31 # possible first bad commit: [2f859137ec629a6619225dd6aedc574904a1019b] source-hash-b4ea08def28a510212f4de355b384e8542c014d4 Maybe 4a7a6b46c0dc779581f271b9e6c13c365eca7ab8
there is a cpu peak, ~ 6 sec. 60 to 100% with below ver., only with active filtering, select all in col C - no peak on ctrl-a, Version: 7.1.0.0.alpha0+ Build ID: 20ba8d8d9f4fcf7d5826fcb3366a9bff0d6a8ca1 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3 Locale: de-DE (en_US.utf8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-06-10_07:16:41 Calc: threaded
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d0cdc461c43f0ce0eda4961311a972edf9e78e2 try to search efficiently with a query with many items (tdf#133867) It will be available in 7.3.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.
Is this really fixed? I just tested with the version below, and even though the CPU didn't go higher than 15% for soffice, I could not change the selection for about 8 seconds after using the Ctrl + A shortcut (i.e., the whole area is selected, but clicking on a cell to change the selection wouldn't work until after 8 seconds). 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
Created attachment 177727 [details] screenshot With 16GB RAM and 16 cores you can see 3 cores going above 60%. 2 of them at 100%. I think there is still more to do.