Description: As a volunteer census checker I often work with spreadsheets of 5K to 6K lines. When I first start working through a sheet response from Calc is great. As I get up to line 2000 however Calc begins to get sluggish - I have been making changes to the data every 5 rows or so on average. Clicking in a field now takes seconds to respond. Scrolling with the mouse wheel ditto, and most other actions including saving the file all take palpable seconds to be actioned. This only occurs from that point in the file onwards. Previously all these actions work in the blink of an eye, so it is not the size of the file per se, but one's position in it, or the number of accumulated changes that is the problem. I am using vn 7.0.5.2 (x64) on W10 19042 with 8 CPU threads. The problem has been around for some time, it is not just this vn of LibreOffice. All other programs and apps work normally. I have tried searching the Community for similar problems, and have tried some of the suggestions but they have made no difference, and I haven't found an issue described in the same way. Steps to Reproduce: 1. Load a file with 5k+ rows 2. Make some changes, save the file etc. All works normally. 3. Continue making changes every 5 rows or so u to around row 2000. 4. Now actions very sluggish. Actual Results: Even after closing and reloading the file, returning to line 1 and making changes the sluggishness is still there. Expected Results: Response should be near instantaneous when the file had not received so many changes. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: CL
Please test with a clean profile, Menu/Help/Restart in Safe Mode. If it doesn't work, please attach a sample file with the steps to reproduce the issue.
Thank you for your prompt response. I have reset my Profile and initially it did improve responsiveness. (I thought I had tried this before but realise now that I put it into SafeMode which made no difference.) Several days further on and it is now starting to get a bit lumpy again. I am working on row 2700 of my current sheet, so about half-way through. If it is OK with you I will continue as is for now and see if response deteriorates further as I work on the piece. It could be another week or so before I finish checking it all, but if it becomes too slow I will send you a copy of the file. Is that OK? Brian
[Automated Action] NeedInfo-To-Unconfirmed
Created attachment 171182 [details] Example ss showing problem
I can confirm that the change of Profile effect was temporary and that the lumpy, sticky behaviour has continued when editing the file from mid-point onwards (there are about 5400 rows). Working on the early part of the sheet is absolutely fine, but the further I progress the more stodgy response is. In particular when saving changes, the Save seems to take several seconds and a few more for the Save icon to change back. But it is all aspects that are affected: scrolling, editing fields, highlighting a row, changing font colour etc. Sometines these are OKish, sometimes not. Saving is always sluggish. I think the problem is happening because I freeze the first three rows of the sheet as these contain heading and column width limit information. When I was preparing a copy of the original file to send these rows were not Frozen and I couldn't undestand why this behaviour wasn't happening in the copy file. Then I tried doing a SaveAs of the work-in-progress file and the stodginess was there. May be a red herring of course ...
Confirmed. Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 4; OS: Windows 10.0 Build 21296; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded Version: 7.1.3.0.0+ (x64) / LibreOffice Community Build ID: 436573acb76714ae9b0ccb8e664911b9696269f4 CPU threads: 4; OS: Windows 10.0 Build 21296; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded Resetting the format for the whole sheet [ctrl-M] solves the issue.
Thank you for this workaround, which has speeded things up nicely. Fortunately the formatting changes that it undid were easily redone, or were no longer needed. Presumably it will progressively get slower again as I work further into the sheet?
I have a similar problem with version 7.2.4 except that I find it happens when editing a set of about 20 Calc files,each about 250k in size, one at a time. After about the 10th file Calc starts to become progressively unresponsive. Even a file save after editing 5 cells in one row can take 10-12 seconds to complete whereas initially it is almost instantaneous.
Dear Brian P, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Following the request made in comment 9 I can confirm that the issue still affects me. Pasted below is the info from About LibreOffice. Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded In my current piece of work the sluggishness began after working through around 500 rows. Scrolling was a bit lumpy and a Save (which I do manually every 20 rows or so) was taking several seconds to complete. I have a workaround, which is to select all rows and click on Clear Direct Formatting. Save. Select all rows from the current one until the end of the sheet and change Font back to Courier New. Save. Work usually continues normally after these actions. Sometimes until the end of the sheet, sometimes I need to repeat the workaround once or twice before getting to the end. I hope this information helps.