Download it now!
Bug 69069 - [EDITING, VIEWING] 100% CPU while Scrolling and copying Columns
Summary: [EDITING, VIEWING] 100% CPU while Scrolling and copying Columns
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, haveBacktrace, perf, regression
: 84167 (view as bug list)
Depends on:
Blocks: Scrolling-PageUpDown Cut-Copy
  Show dependency treegraph
 
Reported: 2013-09-07 14:00 UTC by bmklampe
Modified: 2019-06-30 16:55 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
sample calc spreadsheet (241.77 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-09-07 14:00 UTC, bmklampe
Details
Callgrind output from master (7.80 MB, application/x-xz)
2017-06-17 05:02 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bmklampe 2013-09-07 14:00:52 UTC
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)
Comment 1 retired 2013-09-08 07:04:56 UTC
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.
Comment 2 bmklampe 2013-09-15 08:57:13 UTC
Added reference to closed Bug #42260. 
Verified behaviour of #42260: CPU rises to 100% on one Core, exactly as #69069. Regression bug.
Comment 3 raal 2014-09-27 06:49:59 UTC
*** Bug 84167 has been marked as a duplicate of this bug. ***
Comment 4 QA Administrators 2015-10-14 19:56:09 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2015-12-01 12:51:55 UTC
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)
Comment 6 Robinson Tryon (qubit) 2015-12-09 17:56:47 UTC Comment hidden (obsolete)
Comment 7 Aron Budea 2016-11-16 08:12:29 UTC
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
Comment 8 Aron Budea 2016-11-16 08:35:21 UTC
Actually, I opened bug 103951 on the 5.2 -> 5.3 regression.
Comment 9 Aron Budea 2016-11-16 08:38:36 UTC
Another small issue, even if no changes are made to the file, the dialog to save changes comes up upon closing.
Comment 10 Telesto 2017-06-16 19:33:46 UTC
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
Comment 11 Telesto 2017-06-16 21:12:24 UTC
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)
Comment 12 Buovjaga 2017-06-17 05:02:16 UTC
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
Comment 13 Buovjaga 2017-06-17 05:03:23 UTC
It was confirmed on OS X in comment 1, so OS field was incorrect.
Comment 14 Buovjaga 2018-06-28 12:17:55 UTC
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
Comment 15 QA Administrators 2019-06-29 02:58:20 UTC Comment hidden (obsolete)
Comment 16 bmklampe 2019-06-30 16:55:47 UTC
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 :-)