Bug 113091 - Bump in CPU usage when deleting a bullet row
Summary: Bump in CPU usage when deleting a bullet row
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, perf, regression
: 134818 (view as bug list)
Depends on:
Blocks: VCL-Scheduler CPU-AT-100% Main-Loop
  Show dependency treegraph
 
Reported: 2017-10-13 09:50 UTC by Telesto
Modified: 2020-08-06 20:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (5.11 KB, text/plain)
2017-10-13 09:52 UTC, Telesto
Details
Example file (20.45 KB, application/vnd.oasis.opendocument.text)
2017-10-13 09:52 UTC, Telesto
Details
Example file (22.73 KB, application/vnd.oasis.opendocument.text)
2017-11-06 11:17 UTC, Telesto
Details
Third example (24.04 KB, application/vnd.oasis.opendocument.text)
2018-08-07 14:51 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-10-13 09:50:37 UTC
Description:
Bump in CPU usage when deleting a bullet row

Steps to Reproduce:
1. Open the attached file
2. Set the cursor at the end of a row and hold backspace
3. Notice a bump in CPU usage to 24% when a row is deleted

Actual Results:  
CPU increases to 24% for a short period of time

Expected Results:
Shouldn't happen


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: 6.0.0.0.alpha0+
Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Telesto 2017-10-13 09:52:02 UTC
Created attachment 136947 [details]
Bibisect log

Bibiseced to the following range:

~/bibisect-win32-5.0
$ git bisect bad
3f4cc8db52a676c8bb37ebcf9996e73ef3240f0d is the first bad commit
commit 3f4cc8db52a676c8bb37ebcf9996e73ef3240f0d
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Mon May 25 22:26:52 2015 -0500

    source sha:9b4abcd1c45a646a1ac9120fe1c489ba6bb44e95

    source sha:9b4abcd1c45a646a1ac9120fe1c489ba6bb44e95
    source sha:acaafc03e623ac25d4408605f34d50618926c5d0
    source sha:567f51192483059ec57c16a6045141746d4b01f9
    source sha:ef6f2490a697e7c23fea40c567f751db05f1bbbf
    source sha:2c0189a8a3aeb3668bf6de1ea1958ba475b80a38
    source sha:3da65dc8982167517f19e80a288b049118bc3d23
    source sha:2a0b6705724c4ea65b56eb0f45bccfa253d9fdc2
    source sha:59619dbe971852d5cd35dcc3f78eda9bebeb99aa
    source sha:e7c2b4b981b9b43c31fa442d5596b7a765dbe699
    source sha:6f4dc6af39ecf2f90155205ad097601a8b2f602c
    source sha:ca3700c42238e71684ec1d5f5eacaea4b1ca3b30
    source sha:8da61f23384c7f3f2850a6362765506e4e078862
    source sha:d05a64df34fd143670cb939b72abfb32d6b714c7
    source sha:01f406bc28f53acc5a2734af637aa8074a5d1813
    source sha:b6bb2e9315c9bc3338eaf066df40a969eb4774aa
    source sha:d851e1e3c29afd3315cc763144c6eb92fbef5054
    source sha:7e2a0df7e7b4551698d1d7172ef12ad1e0fd8826
    source sha:b11dba5be288ca5aaed1403093033708f7091c42
    source sha:49439d4a67b06227e56a2855c856e3482323a28a
    source sha:ff52f4e417eb4de5e85388a48a650429b1880762
    source sha:d411dca1ea6bfccb7090d4ceab15119253cac5bf
    source sha:f384496d125255a94bfd5978e0cbe44d6d046adb
    source sha:f33d6800fbdc42aa75477e31be0bba5a4a5a52c1
    source sha:8f9b0c869222e57f738bc25d51cc6364e3c6a65a
    source sha:00717355c2d10bacbae46941b82247d74fd89108
    source sha:2d95bc0510d43c11bb3bd03f590e24ba3d7ca30f
    source sha:ddd4a787ebde1b47e5ddfbd5995e2a0fe6b22ee2
    source sha:0e10b34342bd7b94b69f2eac8c9b1df89a2725f3
    source sha:b380220bc1404ed5a9daa1a28f70696e84543f61
    source sha:5bd1106c3758c8cb0c19b09799970440501fde02
    source sha:3f64e7c16a63fdc330e108cd74182c615d229bb6
    source sha:4c3cea26b84cc70a67ff4eda99b842d8786a3628
    source sha:256c5c3f28ef70b70d38e2e07dfca4baab654612
    source sha:57656eb1fae5ae6c4d3b7542a385a93ff434e4e7
    source sha:49524c6dcf04b9dadef8d2b084cf26abcf70b8a9
    source sha:826143684d2697a8620373dce18fa5f24332d5cb
    source sha:d8305248f687ffa522b56955508d82d60ad5b8c6
    source sha:a74efa665c8199899cd778900de686e2b8710fee
    source sha:e6e8a060ecc6e4fd51cfe88e00d841d546ed5915

:040000 040000 ad77b1a03396af9c8460d94e13cf1c28e5bf54bc dbf71bf6a72509169933f08eb57842c37a266627 M      instdir
Comment 2 Telesto 2017-10-13 09:52:25 UTC
Created attachment 136948 [details]
Example file
Comment 4 Buovjaga 2017-11-04 19:23:39 UTC
It hit 20,4% max with 6.0 and 12% with 4.4.

Version: 4.4.7.2
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: fi_FI

Version: 6.0.0.0.alpha1+ (x64)
Build ID: 7e03c4eed72452fdfb87341214a21956c08ba969
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-26_00:58:29
Locale: fi-FI (fi_FI); Calc: group
Comment 5 Telesto 2017-11-06 11:17:03 UTC
Created attachment 137565 [details]
Example file

Second example (different user case)

1. Open the attached file based on bug 113067
2. Place the cursor and the end of the latest word on the first page
3. Hold backspace and monitor CPU usage

CPU usage will be 25% with LibO6
Start in LibO5 in two steps:
A bump from 10 -> 18% in LibO5
A bump from 18 -> 25% somewhere in LibO5.1

Sidenote: Doing this with Tracking Changed enabled is a horror
Comment 6 Telesto 2017-11-06 11:20:53 UTC Comment hidden (obsolete)
Comment 7 Telesto 2017-11-29 18:27:07 UTC Comment hidden (obsolete)
Comment 8 Telesto 2017-11-29 19:09:41 UTC
Setting to Win only, no repro with Linux
Comment 9 Telesto 2018-08-07 14:51:44 UTC
Created attachment 144013 [details]
Third example

Another example. 
1. Open the attached file (Third example)(Only 2 pages with Ipsum lorem)
2. Enable spell-check (I used German)
3. Delete the yellow marked Hello World stuff by holding delete or backspace (notice the slowdown & CPU usage)
Comment 10 Telesto 2018-08-18 07:08:07 UTC Comment hidden (obsolete)
Comment 11 Jan-Marek Glogowski 2018-08-18 11:11:55 UTC
First: higher CPU usage isn't bad! I expect it and faster processing (less time) after my Scheduler changes, as they removed a sleep from task processing path affecting all tasks. The only real measurement would be instruction count *and* time, eventually even instructions over time, if GUI is involved, which is also hard to analyze.

Second: interactivity / responsiveness is valued higher then speed. MM used to block LO. When I cleaned up the task priorities, interactivity during MM went up a lot, so typing now slows down MM processing visibly. If the platforms are compatible in HW and SW (aka HW acceleration via OpenGL), interactivity differences ("notice the slowdown") might be a valid bug. But generally these are hard to analyze and therefore hard to fix.

BTW: you can test https://gerrit.libreoffice.org/#/c/59279/, which fixes a general Writer background job handling bug, which strangely just seem to affect Windows.
Comment 12 Telesto 2018-08-21 10:48:28 UTC
First of this bug report is a bit of a mess (I caused this myself). I collected all the issues bibisected to same commit in one report. However, root causes might differ..

* Issue 1: Bump in CPU usage when deleting a bullet row (comment 0)
Maybe related to bug 119227 and/or bug 119220

* Issue 2: Slow responding complex document while scrolling; especially noticeable using the scroll bar(comment 7) & with lots of comments around. Time spend looks nearly the same between 4.4.7.2 & 6.2
* MacOS: Always smooth under MacOS with any LibO version
* MacOS: Laggy on Windows since the commit 

* Issue 3: Holding Backspace in a 2 page document will slowdown & lots of CPU time spend (comment 9)
-> Windows; No slowdown with 4.4.7.2 & 4% CPU time spend; now slowdown & 25% CPU time spend
-> MacOS: also a slowdown; however a lot of time spend it at anyhow; difference far smaller.

Yes, I agree higher CPU usage isn't bad! I'm probably not to explicit about the issue. I'm not having any issue with high CPU usage general. The cases where I expect (can't know for sure) that CPU time is spend for silly things (based on comparison with previous versions). I should be more specific. 
 
So again, I'm not against faster processing. And i'm not criticizing any of the changes, either. Only noticing that something seems off. Which profiling might reveal, but I don't know how to do that properly/consistently. Especially when using interaction is needed

Everything is still reproducible with:
Version: 6.2.0.0.alpha0+
Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-08-20_22:43:18
Locale: nl-NL (nl_NL); Calc: CL
Comment 13 Buovjaga 2018-08-21 10:50:57 UTC
(In reply to Telesto from comment #12)
> So again, I'm not against faster processing. And i'm not criticizing any of
> the changes, either. Only noticing that something seems off. Which profiling
> might reveal, but I don't know how to do that properly/consistently.
> Especially when using interaction is needed

You could try this UIforETW thing (if running latest Win 10): https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/
Comment 14 Telesto 2018-09-24 10:21:11 UTC
(In reply to Telesto from comment #7)
> Another example bibisected to the same commit range:
> 1. Open attachment 137973 [details] (bug 106208)
> 2. Scroll down with scroll wheel (sluggish at some parts and 100% CPU usage
> for a single core)

Unwinding: Created a separate report (bug 120102) . More a formality to keep track of the different variants; i'm losing the oversight :-)
Comment 15 QA Administrators 2019-09-26 03:03:36 UTC Comment hidden (obsolete)
Comment 16 Telesto 2020-08-06 20:13:48 UTC
*** Bug 134818 has been marked as a duplicate of this bug. ***