Bug 113105 - CPU running at 100% when adding a table above a large document (since LibO 5.1)
Summary: CPU running at 100% when adding a table above a large document (since LibO 5.1)
Status: RESOLVED NOTABUG
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: bibisected, bisected, perf, regression
Depends on:
Blocks:
 
Reported: 2017-10-13 18:57 UTC by Telesto
Modified: 2017-10-17 11:18 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (2.90 KB, text/plain)
2017-10-13 18:58 UTC, Telesto
Details
Example file (144.02 KB, application/vnd.oasis.opendocument.text)
2017-10-13 20:00 UTC, Telesto
Details
Screencast (1.30 MB, video/mp4)
2017-10-16 07:40 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 18:57:29 UTC
Description:
CPU running at 100% when adding a table above a large document (since LibO 5.1)

Steps to Reproduce:
1. Open the attached file
2. Add a table 3x5 above it and monitor CPU usage

Actual Results:  
CPU utilization at 100% for around 8 seconds 

Expected Results:
5-10% bump for 2 seconds (as before)


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 18:58:36 UTC
Created attachment 136960 [details]
Bibisect log

Bibisected/bisected to:

author	Ashod Nakashian <ashodnakashian@yahoo.com>	2015-07-05 16:05:26 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2015-07-15 07:46:01 (GMT)
commit	b0fde7a912ff3aa370496802f20895b1158b072c (patch)
tree	7b53cc78cc2291ccf2a28083082b37fefb8a2185
parent	82da70787ac12ec9d5791eeac6b48535737ad5b3 (diff)
tdf#38837 Reduce power consumption by minimizing idle timers
Both the document statistics- and state-manager have their
own modified flags. There is a cyclic dependency between the
the two in that updating the document's statistics also marks
the document as modified. Of course when a document is edited
the statistics modified flag is set to trigger an update.

To avoid a perpetual cycle, the statistics manager resets the
document's modified state to that before setting the new
statistics. However, this doesn't reset the statistics
modified flag, which was set when the document was modified
by setting the new statistics. Hence, the statistics thinks
there are modifications in the document when there isn't.

This patch is to make DocumentStateManager::ResetModified()
symmetrical to DocumentStateManager::SetModified() by
reseting the modified flag of the statistics manager.

The idle CPU drops to nil on unmodified documents after this.
However, for modified documents the statistics is recalculated
perpetually until the document is saved. This will need a
different patch to fix.
Comment 2 Telesto 2017-10-13 20:00:18 UTC
Created attachment 136963 [details]
Example file
Comment 3 Telesto 2017-10-15 09:55:43 UTC
Same problem different steps
1. Open Writer, disable spell checking
2. Open the attached file (and wait until it's fully loaded)
3. Press CTRL+A (Writer will be unresponsive for 13 seconds or so with LibO6 and 8 seconds with 5.1.0.3.

The difference between LibO6 and LibO 5.1.0.3 is probably related to Harfbuzz (but that's my theory, didn't check it out)
Comment 4 Telesto 2017-10-15 12:26:07 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2017-10-15 21:27:30 UTC
I can't reproduce it in

Version: 6.0.0.0.alpha0+
Build ID: 8eacd3be08bf6e1a97900624611822de9b00a379
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 6 Xisco Faulí 2017-10-15 21:30:36 UTC
Could you please try in safe mode?
Comment 7 Telesto 2017-10-16 07:40:57 UTC
Created attachment 137008 [details]
Screencast

Screencast after resetting it to default profile; I followed the steps in comment 4 (without the spell checker enabled)

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

I could also reproduce this on MacOS.

The CTRL+A behavior didn't exist before the identified commit. However, opening the file did take for previous versions did take a long time. Combining the initial opening period and the loading when pressing CTRL+A). The some of both is worse than it has been in older versions. I traced it back to bug 113137.

The CTRL+A problem is more obvious on MacOS and Windows, compared to Linux (but there is a spike noticeable 

So I expect this to be a side effect of bug 113137
Comment 8 Xisco Faulí 2017-10-17 09:41:26 UTC
mmm, looking at your screencast, it takes 8 seconds, not 13 seconds.
I also checked in

Version: 6.0.0.0.alpha0+
Build ID: f8b9116e710891cbd8674fe838f04e41346d83b8
CPU threads: 1; OS: Windows 6.1; UI render: default; 
Locale: fr-BE (es_ES); Calc: group

and it takes 5 seconds.
Taking into account it's a 1486 pages file, I would say it's kind of expected.
I'm sorry but I would say it's as RESOLVED NOTABUG
Comment 9 Telesto 2017-10-17 11:18:03 UTC
@Xisco
Hmm.. I should probably be more specific and clear (because I'm mixing two things together).

1. My main point - which this bug should be about - is that LibO is total unresponsive when maken a change (like adding a table) or pressing CTRL+A in a large document. So the first thing happening  I start editing a large document is that will hang the application (in this case 8 seconds).  This didn't happen before the identified commit is pretty unexpected (no such behaviour in Calc or Word)

2. The second part is related to the first one. The last good commit here, is opening slower compared to previous releases. The unresponsiveness while editing is gone, however the loading time when opening the file will increase. Which I still prefer, compared to start editing with a 'hang'. However file opening is noticeable slower compared to for example 5.0.6.3.