Description: I am utilizing librecalc 7.3.7.2 on a Dell precision 7770, below are the specifics i9 12950 HZx24 32 GB dual video cards Ubuntu 22.04.2 LTS Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 24; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.2 Calc: threaded I have been attempting to work with a workbook, which I have been utilizing for 8 years in excel 2010. The workbook was 6.7MB in size, and I have now reduced to 4.7 to get it to even function in Libre. It contains 4 worksheets, following details: worksheet rows columns 1 3361 GK 2 772 X 3 772 AO 4 892 AZ As I said this workbook was originally handled in excel, utilizing a i7 dell precision, (5 years old), Windows 10. I was starting to see some lag on that machine. I made the transition to Ubuntu, I have been utilizing linix on my servers not for 10 years, and I have started moving all my desktops to Ubuntu, got tired of Micosoft. I am also attempting to move all my MS office to Libre. This spreadsheet from the start has been very troublesome on this new machine within the Ubuntu and Libre environment. At times, I have waited up to 5 minutes after positioning the cursor to be able even enter anything in a cell. Watching the CPU usage in TOP, I have seen it go as high as 163%. Since I transitioned the workbook from excel to Libre and ODS, I decided to recreate the workbook and rewrite all of the formulas and links within the workbook. This has helped but the workbook is still very slow and I still see the Soffice+ module jump to over 100% CPU usage, just by position a cursor within the worksheet, and waiting before I can even make an entry or do anything. What is interesting is I have saved the workbook and moved it to a Dell precision T1700 I3-4160 3.6 Ghz 4 GB ram Windows 10 pro 64 bit machine. When I open it with Libre 7.5, I see almost no lag and it functions fine. If I save it in .xlsx format and open it on a Win10 machine with 2010 Excel, it runs fine. It is my guess that the issue is with Libre and Ubuntu 22.04 LTS. Last night, uninstalled and reinstalled my complete Libre package Please advise of how this can be rectified. Kent Steps to Reproduce: 1. rebuild workbook 2. reinstalled libre 3. Actual Results: program is slow, almost unusable within the Ubuntu 22.04LTS environment Expected Results: Function with out any slowdown and locking up Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: SpreadsheetDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 24; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.2 Calc: threaded
Could you give a try to LO 7.4.6 by using this repo https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-still or brand new 7.5.2 by using this repo: https://launchpad.net/~libreoffice/+archive/ubuntu/ppa ?
I will give the 7.5.2 first and let you know what occurs. Thank you for the response Kent
[Automated Action] NeedInfo-To-Unconfirmed
That help a little bit, but a very little bit. The system still hangs up, I waited 3 minutes, after positioning my cursor within the spreadsheet, and received a "force quit/wait" message. cpu usuage is still reporting 99 to 120%, and locks up all my spreadsheets I have open. Move the spreadsheets to office 2010, and I have not delay. Librecalc works great on smaller spreadsheets, but ones that are really having to do a lot of vlookups, matches, and with any size. It is following flat on its face. And this is on a i9 12,950 HZ machine
Ok thank you for the feedback. I got no hint here so uncc myself.
What I find interesting is that as I search the for a resolution to this issue, I have finding references to it going back to 2010. I have found numerous, attempts at different settings and how to make libre office to work on a linux computer, even into 2022, and I have tried most of these suggestions. I would think that over the last 13 years, someone would have attempted to correct this Bug. If you want sample spread sheets, I would be glad to send to you. Actually today, I created a new spread sheet, 8 columns, 700 rows. I cut and pasted an equations in, =if(e2="","",e2*d2). That locked the entire program up for 10 minutes. That equation was copied into all 700 rows. The only way I could get it to free up the system was to do a "pkill soffice.bin". stop the program, and restart. I then copied all of the data into a new spreadsheet, rewrote the equation, and saved under another name. Someone really needs to address this, because it basically makes librecalc, unusable.
Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Created attachment 187300 [details] zipped version of .ods file we have having issues with slow here is a copy of the spreadsheet we are having issues with. hopefully it is not to big. Kent
here is zipped version of the file, if you would like unzipped. please advise. thought it might be to big. Kent
(In reply to Buovjaga from comment #7) > Please attach an example document. > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the document. any further information on the issues that I am having with Libra Calc. I uploaded the file that I was having issues with. It seems to be someplace in the links. I am back to now needing to utilize this spreadsheet. and it just took me 30 minutes, before it would accept a cursor. I am currently running 7.5.6.2 (x86_64). For large spreadsheets LIbra calc is unusable.
I confirm the poor performance, also on Windows. I tested with several old versions, back to 4.3. I don't think it's about the links as the linked files are not available. Also, breaking links via Edit - Links to external files did not help with the performance. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f5bcc34580d02f92af01963155f2d54776a5249b CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
Dear Kent, 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
Timing cell focus change with stopwatch, it is still sluggish, but seems to have improved somewhat. In 7.3, it takes ~12 secs while with master it takes ~9 secs. Arch Linux 64-bit Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 412c0391b56419bea6b0ff7c949ef2ced59a4d6b CPU threads: 8; OS: Linux 6.16; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 18 September 2025
Created attachment 202922 [details] Perf flamegraph of changing focused cell Took a perf trace of clicking to some cell. Looks like lots of time is spent determining row heights for some reason. Arch Linux 64-bit Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5effa8d0977ac9ce13a8e66cbd2302e585c41c6d CPU threads: 8; OS: Linux 6.16; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 22 September 2025
Created attachment 202923 [details] Perf flamegraph of changing focused cell Apparently the traditional flamegraph script doesn't play well with our split debug setup, so here's an SVG exported from Hotspot (View - Export - Flamegraph)
This seems to have something to do AutoShape functionality? But I do not know where in this document those are being used.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/37867ba3a4e44bcd4ff84153a6fb5aa8ebb2d22a tdf#154913 empty is a valid GridOffset It will be available in 26.2.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/11fd1adad3b23b57cfc6ffde88672154b02b15b6 tdf#154913 empty is a valid value for m_aOutRect It will be available in 26.2.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.
Hmmm, so this is essentially a broken document, so I am not interested in making it behave any better. I don't know how it was converted from excel to ODS, but it now contains thousands of invisible and empty shapes, which are slowing everything down.
(In reply to Noel Grandin from comment #19) > Hmmm, so this is essentially a broken document, so I am not interested in > making it behave any better. > > I don't know how it was converted from excel to ODS, but it now contains > thousands of invisible and empty shapes, which are slowing everything down. Feel free to close as fixed, then. Unfortunately Calc does not yet allow to delete shapes via Navigator: bug 132021 If deleting in Calc was implemented, the document could easily be cleaned up as we now support deleting all elements in a category in one go.