Created attachment 132972 [details] example spreadsheet STR ( 0) Download the attached example.ods, 26KB. It a pretty ordinary spreadsheet extending to cell AM277. I first observed this problem on an equivalent tab-separated-values file of 68KB. ( 1) Open example.ods. Observe that cell A1 is current and that the font control shows Liberation Sans 10-point. ( 2) Type "<Ctrl>+A". The program displays all visible cells with a blue background. ( 3) Click on the "expand" down-arrow at the right edge of the font name. Program presents a dropdown list. ( 4) With the mouse, navigate to Liberation Mono and click on that name. All cells are still selected. ( 5) Type "<Ctrl>+1". Program presents dialog "Format Cells". ( 6) Navigate to tab Alignment. Observe that checkbox Properties > "Wrap text automatically" is unchecked. ( 7) Click on that checkbox and then on button <OK>. Program returns focus to the main Calc window; all cells are still selected. ( 8) In a second terminal window issue the command ... top -d 1 -p $( pidof soffice.bin ) Note the CPU time used by soffice.bin. ( 9) In the main Calc window, press the right-arrow key ten times. Cell K1 becomes current. (10) In the second terminal window, note the CPU time used by soffice.bin, and calculate the CPU time used since step (7). Expected: Maybe perhaps about 0.70 seconds. Observed: 12 or 13 seconds. If in step (4) you type "Liberation Mono" instead of selecting it from the drop-down list, the slowdown does not happen. These observations are from debian-stretch with LibreOffice versions (*) daily Linux dbgutil bibisect repository version 2017-04-29 (*) bibisect-43max version oldest (*) Version: 5.2.6.2 Build ID: 1:5.2.6-2, as delivered by debian-stretch I have found several bug reports which may be reporting this problem, but I am unable to determine that with any confidence. The existence of a workaround suggests a lowered priority for this report, but it does not suggest a workaround in any of the similar reports. I am leaving the default bug priority.
Selected version is 5.4 but in your comment is 5.2 When you use [Ctrl+A] you are selecting the whole cells on the sheet not only the visible cells. https://help.libreoffice.org/Common/General_Shortcut_Keys_in#Shortcut_keys_for_editing_or_formatting_documents So you are applying a direct format to 1.073.741.824 cells. The only thing that seems spend a bit of time is (9) what maybe is in relation with redraw the screen. Version: 5.4.0.0.alpha1+ Build ID: 6f53cf281eb3c13fc516ff79decb70b2a87a96d0 CPU threads: 4; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2017-04-29_04:44:04 Locale: es-ES (es_ES); Calc: CL
(In reply to m.a.riosv from comment #1) > Selected version is 5.4 but in your comment is 5.2 Whoops. Actually, it should be the earliest covered by the bibisect-43max repository. I am setting version "4.3.0.4 release". > > When you use [Ctrl+A] you are selecting the whole cells on the sheet not > only the visible cells. > https://help.libreoffice.org/Common/ > General_Shortcut_Keys_in#Shortcut_keys_for_editing_or_formatting_documents Right. In step (2) I described merely the visible result. > > So you are applying a direct format to 1.073.741.824 cells. Actually, that part was surprisingly fast. Getting to the "Format Cells" dialog in step 5 was unreasonably slow, but that is a problem for another day. > > The only thing that seems spend a bit of time is (9) what maybe is in > relation with redraw the screen. But redrawing the screen should be the same with step (4) and with the workaround. > > Version: 5.4.0.0.alpha1+ > Build ID: 6f53cf281eb3c13fc516ff79decb70b2a87a96d0 > CPU threads: 4; OS: Windows 6.19; UI render: GL; > TinderBox: Win-x86@39, Branch:master, Time: 2017-04-29_04:44:04 > Locale: es-ES (es_ES); Calc: CL
Created attachment 132983 [details] result in bibisect-42max Working on debian-stretch in the bibisect-42max repository, I see ... commit s-h date -------- -------- ---------- good 7f989332 9d7c5dcf 2013-08-29 skip 36 commits bad 209d9ca0 a0d3aa1f 2013-08-30 The skipped commits include 21be8edd s-h bcc51fb2, which Joel implicates (<https://bugs.documentfoundation.org/show_bug.cgi?id=78254#c2>) in bug 78254 "Substantial performance deterioration by scroll through cells via macro in LibreOffice Calc". This is evidence that the two bug reports are duplicates. Joel, do you agree? I am adding Joel to cc and adding keywords regression, bibisected.
I am also setting verseion to "4.2.3.3 release".
Created attachment 133102 [details] Callgrind output from 5.4 I did the steps while running with callgrind. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha1+ Build ID: 6e4cba99bb35e6697b94309eedd1a08ebea2dc68 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on May 5th 2016
Setting to NEW
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=bcc51fb2ebdf77a1cc089857775fd742085b45b6..a0d3aa1f50ed158fc0a4d57666f8f9840a81153e
Similar range of commit as in bug 78254. This is a dupe to me... *** This bug has been marked as a duplicate of bug 78254 ***