Description: Deleting/moving an empty sheet in a large calc file slightly slow Steps to Reproduce: 1. Open the attached file 2. Delete/move sheet 11 Actual Results: Slower than expected; takes 10 seconds Expected Results: 2 sec Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 4501a0ba623ad61c5a4e0b807da2e96f0e4ce82c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
1. Open attachment 150858 [details] 2. Insert 10 sheets 3. Copy Column A-C 4. Select sheet 2 t/m 10 (shift click) 5. CTRL+V 6. Move/delete sheet 11
confirm this issue. steps to reproduce : 1. open attachment 142401 [details] 2. insert an empty sheet after KROSCEK 3. delete the newly created sheet took me 162s to delete the empty sheet. Version: 6.4.3.2 (x64) Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
confirmed in comment 2
Comment 2 uses a different file, also in bug 113704
I cannot reproduce with current master, is this still valid?
Lets start with: I have no clue how Calc code functions. So I only find slow and sluggish ;-) Well deleting a sheet takes 13 seconds which kind of matches comment 0 (never seen results of comment 2) 1. Open attachment 150858 [details] with or without Jumbo sheets on 2. Insert 10 new sheets 3. Copy Column A-C of sheet 1 4. Select sheet 2 t/m 10 (shift click) 5. CTRL+V (so pasting it into all 10) -> memory load to 2500 MB (even with 0 undo steps) 6. Delete one sheet of those sheets does take -> 13 seconds 7. Save -> takes more than 120 seconds 8. Close the document ... takes 10 seconds? --- I kind of expect instant deletion.. as there is no interdependence between those sheets (but well I'm not an expert to judge) CPU time appears to be actions by pumping lots of data around: ScTokenArray::Clone -> RtlAllocateHeap formula::FormulaTokenArray::Clear -> RtlFreeHeap -> RtlFreeUnicodeString might be Windows only? --- Offtopic With jumbo sheets LibreOffice being able to import lots of data (columns rows), but the bottleneck is the handling of the data some sensible way Has someone already tried to import some big dummy CVS with plain numbers which is making use of the jumbo sheet dimensions to simple see how well it goes. In the past it seemed the CVS loaded into memory first and next being copied to the sheet, consuming massive amounts of ram.
*** Bug 134301 has been marked as a duplicate of this bug. ***
(In reply to Telesto from comment #6) > Lets start with: I have no clue how Calc code functions. So I only find > slow and sluggish ;-) > > Well deleting a sheet takes 13 seconds which kind of matches comment 0 > (never seen results of comment 2) > 1. Open attachment 150858 [details] with or without Jumbo sheets on > 2. Insert 10 new sheets > 3. Copy Column A-C of sheet 1 > 4. Select sheet 2 t/m 10 (shift click) > 5. CTRL+V (so pasting it into all 10) -> memory load to 2500 MB (even with 0 > undo steps) Repro. > 6. Delete one sheet of those sheets does take -> 13 seconds 8-9 secs on Windows. About half on Linux > 7. Save -> takes more than 120 seconds Same ballpark for me on Windows and Linux. > 8. Close the document ... takes 10 seconds? 5-6 secs on Windows. A bit lower on Linux. Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 04f9a8957c04b8c5abaa58140328d2c83381f4ff CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Jumbo Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: c97a3592c78ce276a353f95ce68c70a8a39174a0 CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded (last commit of 7.4 bibisect repo)
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/52f24a3a1e2ff7f0a599df7bb9caefc8543f7dc4 don't destroy and recreate broadcasters on large changes (tdf#131894) It will be available in 7.4.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.
I took attachment 150858 [details] and inserted 10 sheets and saved again as ODS. In 7.4+ with 28 secs it seems fastest ever from OO when times were up to 54 secs.
(In reply to Timur from comment #10) > I took attachment 150858 [details] and inserted 10 sheets and saved again as > ODS. > In 7.4+ with 28 secs it seems fastest ever from OO when times were up to 54 > secs. You like skipped step 5.. And I probably shouldn't have mentioned saving at all.. at this isn't actually my core concern here..
Dear Telesto, 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
(In reply to Buovjaga from comment #8) > (In reply to Telesto from comment #6) > > Lets start with: I have no clue how Calc code functions. So I only find > > slow and sluggish ;-) > > > > Well deleting a sheet takes 13 seconds which kind of matches comment 0 > > (never seen results of comment 2) > > 1. Open attachment 150858 [details] with or without Jumbo sheets on > > 2. Insert 10 new sheets > > 3. Copy Column A-C of sheet 1 > > 4. Select sheet 2 t/m 10 (shift click) > > 5. CTRL+V (so pasting it into all 10) -> memory load to 2500 MB (even with 0 > > undo steps) > > Repro. > > > 6. Delete one sheet of those sheets does take -> 13 seconds > > 8-9 secs on Windows. About half on Linux This only takes 2.5 secs on Linux now. > > 7. Save -> takes more than 120 seconds > > Same ballpark for me on Windows and Linux. Now only 35 secs on Linux. > > 8. Close the document ... takes 10 seconds? > > 5-6 secs on Windows. A bit lower on Linux. 3.3 secs on Linux. Might be the improvements from bug 131595. Telesto: maybe we can close this? Arch Linux 64-bit Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 493e37d16ce673560ab4309f91308cd5a99944d1 CPU threads: 8; OS: Linux 6.13; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 17 March 2025