Hallo dear LibreOffice dev. team, i'am running LO on a Linux Mint XFCE edition 19.3 (on a HP630 laptop) and 21 (on a Panasonic Toughbook CF-52) for quite some time and since several LO versions. But since versions >=7.1.0 i noticed on both maschines a significant lag when using calc during text/number entering and navigating cells with the arrow key's. subjective pretty much to the point of unuseability. Objectively i would aprox. acount the delay to 200-400ms. But when fast typing, it can be notice pretty easily. Procedure is as follows: 1) open new empty calc spreadsheet 2) try typing "1" (or any other letter) followed by down arrow and try to past a single 1 in each cell per row. you can notice that due to the delay many more 1's end up in a single cell (like "1111") even you press "1" and down-arrow followed by the next "1" in clear succession. I searched the Bug reports and forum entries and found a lot of similar problems with various versions. I tried them without any success. Today i downloaded several older versions and did a side by side comparison with the same user profile and found that it can be tracked down to not present in LO version 7.0.6.2 and present from 7.1.0.0-alpha1 onwards. I hope someone from the dev team will take a look into it, as it seems to be not the usual "reset your user profile" solution in this case. Maybe test it on older HW... If more info or more tests are needed, i'am willing to support. I hope to find a solution, as this problem forces me to not upgrade which i would like to do to participate in newer features. Thanks in advance.
Please copy and paste here, the info in Menu/Help/About LibreOffice (There is an icon to copy) Have you tested with a clean profile, Menu/Help/Restart in Safe Mode
Version: 7.1.0.0.alpha1 Build ID: 987671387712c4f9061d6216ff2f001a7bb9e57b CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded i've tested the issue on both versions with a clean install and also with a resettet profile. i've resetet the profile via SafeMode->Reset to factory settings with both checkboxed enabled. On the Mint21 it's also a clean from ISO OS install without any modifications (but don't make a difference)
Thank you Malte Unfortunately, version 7.1 and 7.0 won't see any more updates. Could you please try with version 7.4 from the LibreOffice website? Much appreciated!
Hallo, as i stated in my initial comment, every version since >=7.1.0 has this issue. I pointed out 7.1.0 because i was able to track it down that the issue is located in some commit between 7.0.6.2 and 7.1.0.0-alpha1 to make the search in the code easier and to reduce the number of potential commits. But i can clearly confirm that the current version 7.4.3. shows the same phenomena.
Thank you. Can you please see if you can reproduce the same issue with a different VCL, by running Calc with these commands from a terminal: SAL_USE_VCLPLUGIN=gen libreoffice7.1 --calc SAL_USE_VCLPLUGIN=kf5 libreoffice7.1 --calc The interface should look different to the default GTK3.
Hallo, sorry for late response, had a lot to do last week. subjective results are as follows: 7.0.6 = fastest even with kf5 7.0.0.1-alpha1 with GEN = about 50% faster (in between 7.0.6-kf5 setting and 7.0.0.1=kf5 setting) 7.0.0.1-alpha1 with KF5 = as slow as reported in my initial post. 7.4. by the way is the same laggyness as 7.0.0.1. I hope that info is helpfull
(In reply to Malte S from comment #6) > subjective results are as follows: > 7.0.6 = fastest even with kf5 > 7.0.0.1-alpha1 with GEN = about 50% faster (in between 7.0.6-kf5 setting and > 7.0.0.1=kf5 setting) > 7.0.0.1-alpha1 with KF5 = as slow as reported in my initial post. > > 7.4. by the way is the same laggyness as 7.0.0.1. I assume you mean "7.1.0.1" where you wrote "7.0.0.1"?
"I assume you mean "7.1.0.1" where you wrote "7.0.0.1"?" oh yes, sure... sorry for the typo. it's 7.1.0.0-alpha1
[Automated Action] NeedInfo-To-Unconfirmed
I tried: enter "1" + press Enter, many times repeated. I _thought_ I could reproduce the first time, but then tried again and couldn't reproduce with: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.2-0ubuntu2 Calc: threaded And with 7.4.3 neither. Not sure if that first time was a fluke. I made sure to create a VM with only 2 cores. Using Linux Mint 21 with Cinnamon. I might try with XFCE later.
I've tried the same. It seems as if you do the same multiple times it becomes faster the 2nd, 3rd, etc. times. But despite the entering becoming faster, 7.1.0.0 is always slower then 7.0.6 version. But if i work on not empty spreadsheets (especially ones which where original .XLS files) it keeps a consistent issue. I will try to see if i can identify a pattern here. Not sure if we speak about the same rootcause then. But effect in the end is the same.
Created attachment 184014 [details] File to demonstrate issue I've did some testing concerning slow data entry with non-empty spreadsheets. It seems as if after a certain content level the "speedup issue after initial data entry is non existing any longer". If you take the example content of the attachment and just pare column A-J into a new spreadsheet you can notice faster input after initial input is done. But if you add columns K-X the data entry stays significantly more slow then in the 7.0.6.2 version of calc. Also in 7.0.6.2 the data entry is always equaly fast from the 1st data entry on. Hope that helps analyzing.
Malte, we recently identified a performance issue that appeared in LO 7.1, and I'm wondering if you are seeing the same one. Can you please test if removing the Formula Bar (View > Formula Bar) resolves the performance issue? If that's the case, we have a duplicate of bug 152657.
Hi, i've tested with Formula Bar disabled and it definitely improves the speed. Overall 7.0.6.2 is still faster with cell entry then everything >=7.1.0.0 but the Formular bar made >50% speed improvement. So i would confirm that this has something to do with the speed decrease. It brings the newer Versions (at least with the calc spreadsheet size i used for testing) in the region of having a workable speed on an older machine. I would continue testing with bigger spreadsheets as i have the impression that overall performance drops there additionally the more content is in the file. And i would appreciate if you look further what could slow down the versions after 7.1.0.0, as the speed from 7.6.0.2 was awesome compared to newer versions. But never the less, disabling Formular Bar is a bit step forward. Thanks.
Thanks for testing. Shame that that regression doesn't account for the whole of the lag you noticed. Given that I can't reproduce, if you want to help further (and can clearly see the difference even without the status bar), you could try bibisecting the issue. It helps us identify exactly the commit that introduced the issue. The repository you would need is this one: https://bibisect.libreoffice.org/linux-64-7.1.git The Linux bibisecting instructions are here: https://wiki.documentfoundation.org/QA/Bibisect/Linux#Bibisecting_the_Bug You can let us know in the QA chat if you need a hand with it.
Hi, i will get myself familiar with the Bibisecting procedure and will let you know about the results. Just be a bit pacient as i'am sometimes quite busy in my day job but i will post results here once done. i'am glad to help
It has been a couple of years, so it would be good to hear what the status is with this issue. Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
The issue is still present. Unfortunately i never found the time for a detail disecting the different commits between version 7.0.6.1 and 7.1.0.0 which causes the performance drop in detail. I have some vacation in June, i try to find some time for a more detailed testing then. If someone else can supporting in testing the different versions in between would also be highly appreciated. Sorry for not updating the ticket for so long...
(In reply to Malte S from comment #18) > The issue is still present. Unfortunately i never found the time for a > detail disecting the different commits between version 7.0.6.1 and 7.1.0.0 > which causes the performance drop in detail. > > I have some vacation in June, i try to find some time for a more detailed > testing then. > > If someone else can supporting in testing the different versions in between > would also be highly appreciated. > > Sorry for not updating the ticket for so long... Alright, but first of all it would be good to test with version 25.2.
Got bisecting working ;-) I can confirm, performance issue is still present in version 25.2 I will redo the bisecting process (just to double check) but my 1st attempt reviled: dc406913109378c26e625130439de75e6f46174c is the first bad commit commit dc406913109378c26e625130439de75e6f46174c Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat Oct 3 08:46:14 2020 +0200 source 5acdb23a413ce82a279eb4fee0ddf867e989fec8 source 5acdb23a413ce82a279eb4fee0ddf867e989fec8 instdir/program/libvcllo.so | Bin 15567952 -> 15567952 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-)
(In reply to Malte S from comment #20) > Got bisecting working ;-) > I can confirm, performance issue is still present in version 25.2 > I will redo the bisecting process (just to double check) but my 1st attempt > reviled: > dc406913109378c26e625130439de75e6f46174c is the first bad commit > commit dc406913109378c26e625130439de75e6f46174c > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Sat Oct 3 08:46:14 2020 +0200 > > source 5acdb23a413ce82a279eb4fee0ddf867e989fec8 > > source 5acdb23a413ce82a279eb4fee0ddf867e989fec8 > > instdir/program/libvcllo.so | Bin 15567952 -> 15567952 bytes > instdir/program/setuprc | 2 +- > instdir/program/versionrc | 2 +- > 3 files changed, 2 insertions(+), 2 deletions(-) Hmm, that commit is quite a small one that is targeting Skia. Skia is used to render the UI, but not on Linux's gtk3 UI that you use. GDI in particular that the file is about is a Windows graphics thing: https://learn.microsoft.com/en-us/windows/win32/gdi/windows-gdi
yes, i was also confused that this commit should be the problem. But to be honest, the bisect process showed some inconsistent results. As it's necessary to enter a value + arrow down manually in quick succession makes it a bit hard to measure precise differences. It defiantly makes a difference if you use a new (empty) spreadsheet or one with more content (see example attachment). In a non empty sheet the effect is much more prominent. Is anyone else able to reproduce the issue with a low performance PC? I can 100% say for sure, that there is a significant performance difference between the two versions mentioned above. So it must be somewhere in any of these commits leading to 7.1.0.0
Bug 154602 is similar, but it was bibisected (in bug 154602 comment 13) to a commit in version 7.3. It has several reports in its See Also.
Hi, did some manual bisecting and found another commit which hopefully is the right one. It's cc2060fb21d48d775e5a85b9080c10589ab7287e from 25.09.2020. I've checked manually and the commit before that 4e7f0727f3b25c0f317e56e852aa4c2fd39ee355 is much better performance wise. I hope you can confirm that cc2060 is indeed relevant for my setup/issue :D
(In reply to Malte S from comment #24) > Hi, did some manual bisecting and found another commit which hopefully is > the right one. It's cc2060fb21d48d775e5a85b9080c10589ab7287e from 25.09.2020. > I've checked manually and the commit before that > 4e7f0727f3b25c0f317e56e852aa4c2fd39ee355 is much better performance wise. > > I hope you can confirm that cc2060 is indeed relevant for my setup/issue :D Hmm, its topic is "Cleanup Sidebar theme", so one might expect that any effect is not seen, if the Sidebar is hidden. Do you see the slowness even if the Sidebar is hidden?
I can confirm, if the sidebar is completely closed (not only minimized) the performance increases. I guess this confirms that the change has the observed impact. Sorry again for the long pause and thanks for all the help during the analysis.
(In reply to Malte S from comment #26) > I can confirm, if the sidebar is completely closed (not only minimized) the > performance increases. I guess this confirms that the change has the > observed impact. > > Sorry again for the long pause and thanks for all the help during the > analysis. Ok, that's cool. Andreas was mainly working on icon design and UI tweaks and has not been active for a while. I might show this to someone who has experience with optimisations. I don't understand why the code change would cause slowness as it seems to be simplifying things. For the record, I don't reproduce it with the typing steps from comment 0. Arch Linux 64-bit Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 9ab2578b3a832e75ad3c71477ad1850be236cc3f CPU threads: 8; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 20 May 2025
The reason why you might not be able to see the issue with my initial description in comment 0 is, because it becomes much less prominent in an empty table. But the more content the table has, the more you see it. I also assume you really need an older PC to make it noticeable as well. Maybe try to compare my attached example file which has some content. Or if you have a faster CPU, maybe try a table much more content. I don't know if there is a performance cap at a certain content level, but i can see one with a "real life example" vs. completely empty table for sure.
(In reply to Malte S from comment #28) > The reason why you might not be able to see the issue with my initial > description in comment 0 is, because it becomes much less prominent in an > empty table. > > But the more content the table has, the more you see it. > I also assume you really need an older PC to make it noticeable as well. > > Maybe try to compare my attached example file which has some content. > Or if you have a faster CPU, maybe try a table much more content. I don't > know if there is a performance cap at a certain content level, but i can see > one with a "real life example" vs. completely empty table for sure. Now I tried with attachment 184014 [details] but could not repro. I have an i7-6700K from 2016 and 32 GB RAM, but I am able to reproduce many other performance issues noticeably.
your i7-6700K despite from 2015, my Pentium B950 is ~60% slower on single thread and 90% slower on multi thread. I assume thats why you do not see it... i know my Maschine is ancient :D