Bug 114012 - High CPU usage when deleting some text with backspace
Summary: High CPU usage when deleting some text with backspace
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
: 116013 (view as bug list)
Depends on:
Blocks: CPU-AT-100% VCL-OpenGL
  Show dependency treegraph
 
Reported: 2017-11-23 16:36 UTC by Telesto
Modified: 2018-09-24 10:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Bibisect log (2.91 KB, text/plain)
2017-11-23 16:37 UTC, Telesto
Details
Blind patch. (1.52 KB, patch)
2018-06-07 15:40 UTC, Miklos Vajna
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-11-23 16:36:12 UTC
Description:
Spinoff of bug 113091 (based on comment 5). The CPU usage is pretty high for deleting some content with backspace.

This is about the small bump (of around 5%).

Steps to Reproduce:
1. Open attachment 137565 [details] 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



Actual Results:  
A bump in CPU usage from 20% (LibO5.0) to 25% (since 5.1)

Expected Results:
Should be less CPU intensive


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 6.0.0.0.alpha1+
Build ID: c24c32bf71b8e64bd0d36e511f554e1f6c015842
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-11-22_23:15:41
Locale: nl-NL (nl_NL); Calc: group threaded

and in 
5.2


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Telesto 2017-11-23 16:37:27 UTC
Created attachment 137946 [details]
Bibisect log

Bisected to:

author	Miklos Vajna <vmiklos@collabora.co.uk>	2015-08-07 14:35:11 (GMT)
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2015-08-07 14:35:23 (GMT)
commit c64a7ce1fcd1e30956a77530d0b76ad493841024 (patch)
tree 723796de700b511614ffeb9c36b12284fa5d3255
parent a6c7a0bf105c399d087e2d9f843dbd9b175fdf42 (diff)
Resolves: tdf#92982 vcl rendercontext: handle buffered paint of vcl::Cursor
Instead of painting on the vcl::Window directly, take a
PaintBufferGuard, and use the vcl::RenderContext of it, that may be
either the vcl::Window or the toplevel frame's buffer.

Trigger the paint of the buffer by informing the guard what area was
painted. In case of direct painting, both the ctor and the dtor of the
guard is a NOP.

This means that finally we can also assert Invert() calls on the output
device, so that direct paint can't happen when double-buffering.
Comment 2 Buovjaga 2017-11-24 16:37:25 UTC
65% for me without Auto spell check and 100% with Auto spell check.

Arch Linux 64-bit
Version: 6.0.0.0.alpha1+
Build ID: 008673c23db0c812eb0b48a1c29ab88b48aaa867
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on November 23rd 2017
Comment 3 Xisco Faulí 2018-03-01 11:34:34 UTC
Adding Cc: to Miklos Vajna
Comment 4 Buovjaga 2018-05-23 08:33:01 UTC
*** Bug 116013 has been marked as a duplicate of this bug. ***
Comment 5 Miklos Vajna 2018-06-07 13:57:22 UTC
I assume that 100% and 25% is the same when you have 4 threads, just Linux interprets that as 100% and Windows divides the number by the number of threads.

I don't really see a performance improvement if I undo the above commit on Linux, doing an optimized Windows build now, hopefully it'll be visible there.
Comment 6 Miklos Vajna 2018-06-07 15:40:24 UTC
Created attachment 142591 [details]
Blind patch.

I think what's misleading is that c64a7ce1fcd1e30956a77530d0b76ad493841024 on 2015-08-07 introduced the commit cited above, but then later on 2015-09-04 012a7115d11c6bc2f4c3c33180c319d043a22d51 optimized the non-double-buffered codepath.

That means anything after that is really the same as the old state by default.

Could you confirm that the attached patch doesn't fix the problem? (It's effectively a revert of both commits). If so, this is an opengl perf bug, not a regression.

Thanks!
Comment 7 Buovjaga 2018-06-07 15:50:16 UTC
(In reply to Miklos Vajna from comment #6)
> Created attachment 142591 [details]
> Blind patch.

No change on Linux.
Comment 8 Miklos Vajna 2018-06-08 13:13:56 UTC
OK, then what remains is a performance problem, the above later commit already addressed the regression part.

I also add this to the GL tracker as the duplicate bug 116013 is specific to GL.
Comment 9 Telesto 2018-09-24 10:25:20 UTC
Lets close as a margin issue