Description: Following the expanded columns in 7.4, new columns appeared alongside my previously hidden range of columns. I hid these columns for each worksheet in the workbook. Doing so resulted in significantly reduced performance, such as having to wait for the program to catch up to my typing. My CPU usage will hit 80%+ when typing alongside the reduced performance. For reference, this particular workbook: - Has 16 worksheets - Uses minimal formulas - Each worksheet has < 500 rows. I additionally have reference files which highlight the change in performance before and after hiding columns. Steps to Reproduce: 1.Hide most columns across several worksheets in a single workbook. 2.Typing and general performance will be sluggish and consume high CPU use. Actual Results: Reduced performance and increased CPU usage. As I type, each key takes a few seconds to visually appear. Once I finish typing, text eventually appears Expected Results: No change in performance. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: I also tried loading the document in safe mode to see if any differences were noticed, but performance remain impacted.
Created attachment 181930 [details] Example of document with reduced performance due to hidden columns.
Created attachment 181931 [details] Example document with columns un-hidden, and exhibits normal performance.
I can't repro Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL
I shared the files attached here with another individual running Linux. My machine has Arch, but I believe they are using another distro. They were able to immediately confirm the behavior described above. Additionally, unhiding all columns immediately restored normal performance - but just for that particular worksheet. Again, this behavior was able to be replicated on another machine. Let me know if there is anything I could provide to help further debug this issue.
Let's see if someone with Linux can reproduce it.
I could notice that the file from attachment 181930 [details] (the one with hidden columns) is somewhat slower in LO 7.4 and much faster in LO 7.3.5. The difference in speed is more noticeable when typing values in the "Categories" sheet. Slower in Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded Faster in Version: 7.3.5.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1 Calc: threaded
(In reply to Rafael Lima from comment #6) > I could notice that the file from attachment 181930 [details] (the one with > hidden columns) is somewhat slower in LO 7.4 and much faster in LO 7.3.5. > The difference in speed is more noticeable when typing values in the > "Categories" sheet. Difference is that 7.3 does not support as many columns: "The data could not be loaded completely because the maximum number of columns per sheet was exceeded." For me, the only noticeable slowness is when zooming out. Arch Linux 64-bit, X11 Version: 7.4.5.1 / LibreOffice Community Build ID: 40(Build:1) CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.4.5-1 Calc: threaded
Created attachment 184957 [details] Perf flamegraph Took a perf trace of zooming out in the spreadsheet. I see lots of time spent in svx::frame::Array stuff. --enable-symbols build Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 668f55b65849012b359d7d6b9386113facbadc57 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/050ff677a4888ac039a913fedbe950bda2dc037d tdf#150534 re-arrange Style class fields It will be available in 7.6.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/db88842170a041267b55dda64f8280a1394202b8 tdf#150534 use unordered_set for checking of lines already crossed It will be available in 7.6.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/e2c811e6f9c0b2de47153a70a783f4d808eab3ab tdf#150534 reduce allocation in SdrFrameBorderPrimitive2D It will be available in 7.6.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.
Per the commit's suggestion, I installed the latest Daily build to check the files previously shared. I used the most current build as of the posting of this message, which the full version being `7.6.0.0.alpha0+` The files above still exhibit noticeable performance degradation when columns are hidden. Typing, scrolling, and general interface interaction causes the application to slow down and CPU usage to increase. Showing the hidden the columns results in immediately improved performance for the worksheet.
I think last patches are not in the https://dev-builds.libreoffice.org/daily/master/current.html
Sorry they are.
Created attachment 187013 [details] Clip of high CPU usage when attempting to scroll on a blank spreadsheet with hidden columns. Additionally, there is still high CPU usage when scrolling without hidden columns. But it is just barely enough not to cause major performance degradation.
Updating to note that this bug still occurs on newer versions of LibreOffice.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e27d4cc31e04be4c47b5085dfa2363ee45457e8a tdf#150534 reduce the memory consumption of cells when calculating It will be available in 24.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.
apologies this has taken me a bit to get around to testing! I installed the latest daily build as of today, but the bug still seems to be present. The dev version i tested was 24.2.0. I'm attaching a clip of me scrolling with this version, though its admittedly low res. The application freezes completely when scrolling with hidden columns still, and you can see high CPU usage when i attempt to scroll. Leaving the bug status as Resolved/Fixed just in case something is incorrect on my end.
Created attachment 188919 [details] Dev 24.2.0 Scroll Test
Dylan: from your video I see you are on Wayland. Does the same happen under X11? Please copy and paste here the contents of your Help - About by clicking the copy button. This allows us to know more about your system.
Yes, I am on wayland! Here is the copy and paste of the version information: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 218a7650a5cf03f895bed19c68d6f02daec536e9 CPU threads: 32; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I went ahead and loaded up the same dev build in X11, and the issue is not present there (KDE X11, to be specific).
(In reply to Dylan Wolters from comment #19) > Created attachment 188919 [details] > Dev 24.2.0 Scroll Test I can confirm that the issue persists in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3ce30d6a1ea1cd3e392cb21fa37102795578eeb7 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded Notice that I'm on KDE + X11. With the document "template-broken.ods" I get huge scroll lag. When I show the hidden columns, all is fine and scroll is good again.
As for comment #22, here's my system info: Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.8 Kernel Version: 6.2.0-26-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1660/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B450M DS3H
i should clarify that when i tested on KDE X11, i did notice there was some slowdown but it was nowhere near the severity I witnessed under Wayland (which often meant having to kill the process). Here are my system specs for contrast (when running under wayland): Operating System: Arch Linux KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6950 XT
I showed your comments to Noel and he said further work would require vasts amounts of code changes and he is not planning to continue on this. So maybe I will change the status back to NEW and someone else can pick this up.
More thoughts from Noel: possibly what we need for that situation is way to shrink the actual limits of the sheet to something smaller instead of hiding the columns. That would however be a new feature with new UI, etc probably what we want is a per-sheet dialog to alter the sheet limits