Bug 107168 - High use of CPU when clone formatting more than once
Summary: High use of CPU when clone formatting more than once
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium minor
Assignee: Not Assigned
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: CPU-AT-100% Clone-Formatting
  Show dependency treegraph
Reported: 2017-04-14 19:59 UTC by Martin M.
Modified: 2019-06-11 12:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Martin M. 2017-04-14 19:59:33 UTC
When using 'extended' clone formatting (double-clicking the clone formatting icon), after applying format for the first time, the CPU is 100% of a core until the operation is finished (by for example pressing ESC).

Steps to Reproduce:
1. Type two lines of text
2. Select second line and bold it
3. Without deselecting second line, double-click the clone formatting icon
4. Clone the format to the first line
5. Wait

Actual Results:  
The CPU use is 100% of a core until you manually end the cloning operation.

Expected Results:
The CPU use should be no greater than the normal, idle one.

Reproducible: Always

User Profile Reset: Yes. Same result.

Additional Info:
Same result with OpenGL off. I personally reproduced in and (x64) in Windows 10 with Intel HD 4000 GPU. Somebody in IRC could reproduce the same behavior in Windows 10 with (x64) and (build 4e74f1d5ae6da4f4d24ab96bca022cefec410db4, x86).

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Comment 1 Mike Kaganski 2017-04-14 21:20:57 UTC
Somebody from IRC here :)

Reproducible with Version: (x64)
Build ID: 13010a13177025f633c9b85adcb3edf6920e44e3
Threads 4; Ver: Windows 6.19; Render: default; 
Locale: ru-RU (ru_RU)

Not reproducible with Version: (x64)
Build ID: 0b48731919433e46e4fda7e5a5ca27c08c28b981
Locale: ru-RU (ru_RU)

$ git bisect log
# bad: [05d11632892a322664fb52bac90b2598b7fb7544] source sha:5616d22b57a9a5e57d545e912e029162a230829b
# good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source sha:ab465b90f6c6da5595393a0ba73f33a1e71a2b65
git bisect start 'master' 'oldest'
# good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source sha:4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f
git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f
# good: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source sha:1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2
git bisect good 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6
# good: [11864a7db429a57aeea021e0b3f1fb1412282d32] source sha:e5b721a14c1c8e5261a70588b30353cbb5bd55c6
git bisect good 11864a7db429a57aeea021e0b3f1fb1412282d32
# good: [7d52a87c0aa24498584ec522705cfae3a3a5a038] source sha:479df22d0b4b0e0393fcf621e7380b38415bcef8
git bisect good 7d52a87c0aa24498584ec522705cfae3a3a5a038
# bad: [bea538a879f50238f4c9c6f05e3d7390db9d76c7] source sha:7289a140fc68dc898ba2b2357cc960968195f236
git bisect bad bea538a879f50238f4c9c6f05e3d7390db9d76c7
# good: [ad146f48b7f50d159d5b96f1c118cdb8412a98b8] source sha:91cbbb7797f048834b51690e9fab60aa778b1e44
git bisect good ad146f48b7f50d159d5b96f1c118cdb8412a98b8
# good: [773530329ceb1603b45cab2fadb112d5f2edbc9e] source sha:6525d1663f8d03e2c28e626fadc2e3e848798224
git bisect good 773530329ceb1603b45cab2fadb112d5f2edbc9e
# good: [121c8d35cf9a9ef1c1312f5e75b8d060ec842ea1] source sha:f42d03f3e9393db693ed753837ce25e1f43297df
git bisect good 121c8d35cf9a9ef1c1312f5e75b8d060ec842ea1
# good: [de062e1c9e15e295d26a8bfe0de29395f9257cbc] source sha:7c654ee9d51a752e02c0a972de27d699ab5b649a
git bisect good de062e1c9e15e295d26a8bfe0de29395f9257cbc
# good: [98474941bf5d0775ec51591c8761b93974dd62f6] source sha:9015e72459b5112b0ebddf61c42cae7e8c35f734
git bisect good 98474941bf5d0775ec51591c8761b93974dd62f6
# good: [a6d2f799c50c1b476f3f5e5761350609c04dd3ad] source sha:9b52b8999be86e5c6e5f5901b2640b16f08a2323
git bisect good a6d2f799c50c1b476f3f5e5761350609c04dd3ad
# bad: [43c1e1712fb204a3e37288604237436f9d328cc0] source sha:22ebafe8897239696f46df6f093054d16285004a
git bisect bad 43c1e1712fb204a3e37288604237436f9d328cc0
# bad: [564a31a6903a2ae896058e5509236ccdc91062a3] source sha:87199d3829257420429057336283c55be6ae7481
git bisect bad 564a31a6903a2ae896058e5509236ccdc91062a3
# first bad commit: [564a31a6903a2ae896058e5509236ccdc91062a3] source sha:87199d3829257420429057336283c55be6ae7481
# bad: [564a31a6903a2ae896058e5509236ccdc91062a3] source sha:87199d3829257420429057336283c55be6ae7481
git bisect bad 564a31a6903a2ae896058e5509236ccdc91062a3
# first bad commit: [564a31a6903a2ae896058e5509236ccdc91062a3] source sha:87199d3829257420429057336283c55be6ae7481

Comment 2 Mike Kaganski 2017-04-14 21:28:35 UTC
The problem is seen as

IMPL_LINK( DocumentTimerManager, DoIdleJobs, Timer*, pIdle, void )
calling pIdle->Start();
(see sw/source/core/doc/DocumentTimerManager.cxx:124)
which starts timer with nPeriod = Scheduler::ImmediateTimeoutMs,
which makes idle handler to call IMPL_LINK( DocumentTimerManager, DoIdleJobs, Timer*, pIdle, void ).
Comment 3 Aron Budea 2017-07-30 21:07:52 UTC
If that is the responsible commit, the behavior should not occur in, as that commit hasn't been backported to 5.0, right? Could bug 108937 be a duplicate of this?
Comment 4 Telesto 2017-10-13 15:46:40 UTC
No repro with:
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
Comment 5 Xisco Faulí 2018-06-05 21:14:16 UTC
Adding Cc: to Michael Meeks
Comment 6 QA Administrators 2019-06-06 02:54:06 UTC Comment hidden (obsolete)
Comment 7 Martin M. 2019-06-11 12:22:20 UTC
Can't repro anymore in:

Version: (x64)
Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: es-ES (en_US); Calc: group