Created attachment 85396 [details] sample calc spreadsheet see attached .ods for verification Scrolling in Sheet 'werte' sets one core to 100% cpu, same when selecting row 52 from column A to BV, copy and pasting the row. OS: Windows 7 Home Premium, 64 Bit, German Java: Verion 7 Update 25, 32 Bit (Build 1.7.0_25-b16) Calc.exe Version 3.6.3.2 (Build ID: 58f22d5)
Confirming -> NEW Open example file on OS X 10.8.4, LO 4.2. Version: 4.2.0.0.alpha0+ Build ID: 6dbf3cd4123a24ee1f5169aaa02cb06ae3eefaaf scrolling around in sheet "werte" works fine but trying to copy a column leads to a crash.
Added reference to closed Bug #42260. Verified behaviour of #42260: CPU rises to 100% on one Core, exactly as #69069. Regression bug.
*** Bug 84167 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
Scrolling is a bit slow as is copy&pasting row 52 from column A to BV, but no crash. Please retest! Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a7c3a2a9be83686657c06f37d521f9f6d2004ddd Threads 4; Ver: Windows 6.1; Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2015-11-28_04:39:18 Locale: fi-FI (fi_FI)
Migrating Whiteboard tags to Keywords: (perf)
I see performance regression with the attachment in 5.3 daily build / Windows 7. Opening the spreadsheet takes ~45s (about twice as much as with 5.2.3.3), and scrolling the chart screen is sluggish, while it wasn't so before. Version: 5.3.0.0.alpha1+ Build ID: 0d6f974b97597744119db9dc3d193aeeb8f9d3fa CPU Threads: 4; OS Version: Windows 6.1; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@39, Branch:master, Time: 2016-11-11_23:56:36 Locale: hu-HU (hu_HU); Calc: CL
Actually, I opened bug 103951 on the 5.2 -> 5.3 regression.
Another small issue, even if no changes are made to the file, the dialog to save changes comes up upon closing.
Scrolling the sheet "Werte" horizontally and vertically is slow with: Version: 6.0.0.0.alpha0+ Build ID: cbf371e07fd5dea1ea08a1f299360d1273961ebd CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-14_23:13:57 Locale: nl-NL (nl_NL); Calc: CL and with Versie 4.0.0. but not with LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5
Buovjaga: Would you mind to test if this is really Win only? Bibisecting on Windows looks nearly impossible. Windows Bibisect repositories go back to 4.3 if I understand correctly (https://wiki.documentfoundation.org/index.php?title=QA/Bibisect/Windows)
Created attachment 134076 [details] Callgrind output from master Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 5c81adc51a05a016e754de7961d3a7bdb4494e01 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 16th 2017
It was confirmed on OS X in comment 1, so OS field was incorrect.
I bibisected on Linux with 43all for the horizontal scroll in werte sheet and it blamed this range: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=18e6e7d929c2be209407ed2e56b8ec4d5e6c4900...9ca02a663c3eee2698eb360dd5dc7afb1951e743 It was a bit challenging because the difference of CPU hammering is not very big. Guessing, the reason could be https://cgit.freedesktop.org/libreoffice/core/commit/?id=435c117c1c684d4603f557ed821c1fd5ee057086 commit 435c117c1c684d4603f557ed821c1fd5ee057086 (patch) tree ef8ebdfb4cb970999adcc3416b967511a53af490 parent 904763b1134bdd84a4e64de1e037da5cac192f27 (diff) some optimization of ScAttrArray::GetLastVisibleAttr() Method assumed that not much attribution happens below data and started from the end of attribution, in the case of not much attribution it worked fine. For the case of many differently formatted areas with a sufficiently large area of visibly equal attribution near data end it was a bottle neck looping over unnecessarily many comparisons. Start at data end instead. For the case of not much attribution it doesn't really matter, and for the case of no sufficiently large area below data end it doesn't matter at all and compares the same number of entries. The drawback would be a large area near attribution end with many small areas between data end and the large area. Observed with test case of fdo#46160 Adding Cc: to Eike Rathke
Dear bmklampe, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Verified with Version: 6.1.6.3 (x64) Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded on OS Windows 10 Home Version 1903 Build 18362.175 CPU is still high but calc.exe ist responsive and no crash. Thanks for the work :-)