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
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.
Created attachment 136963 [details] Example file
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)
This is probably a side effect of bug 113105
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
Could you please try in safe mode?
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
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
@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.