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
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 9b4abcd1c45a646a1ac9120fe1c489ba6bb44e95 source 9b4abcd1c45a646a1ac9120fe1c489ba6bb44e95 source acaafc03e623ac25d4408605f34d50618926c5d0 source 567f51192483059ec57c16a6045141746d4b01f9 source ef6f2490a697e7c23fea40c567f751db05f1bbbf source 2c0189a8a3aeb3668bf6de1ea1958ba475b80a38 source 3da65dc8982167517f19e80a288b049118bc3d23 source 2a0b6705724c4ea65b56eb0f45bccfa253d9fdc2 source 59619dbe971852d5cd35dcc3f78eda9bebeb99aa source e7c2b4b981b9b43c31fa442d5596b7a765dbe699 source 6f4dc6af39ecf2f90155205ad097601a8b2f602c source ca3700c42238e71684ec1d5f5eacaea4b1ca3b30 source 8da61f23384c7f3f2850a6362765506e4e078862 source d05a64df34fd143670cb939b72abfb32d6b714c7 source 01f406bc28f53acc5a2734af637aa8074a5d1813 source b6bb2e9315c9bc3338eaf066df40a969eb4774aa source d851e1e3c29afd3315cc763144c6eb92fbef5054 source 7e2a0df7e7b4551698d1d7172ef12ad1e0fd8826 source b11dba5be288ca5aaed1403093033708f7091c42 source 49439d4a67b06227e56a2855c856e3482323a28a source ff52f4e417eb4de5e85388a48a650429b1880762 source d411dca1ea6bfccb7090d4ceab15119253cac5bf source f384496d125255a94bfd5978e0cbe44d6d046adb source f33d6800fbdc42aa75477e31be0bba5a4a5a52c1 source 8f9b0c869222e57f738bc25d51cc6364e3c6a65a source 00717355c2d10bacbae46941b82247d74fd89108 source 2d95bc0510d43c11bb3bd03f590e24ba3d7ca30f source ddd4a787ebde1b47e5ddfbd5995e2a0fe6b22ee2 source 0e10b34342bd7b94b69f2eac8c9b1df89a2725f3 source b380220bc1404ed5a9daa1a28f70696e84543f61 source 5bd1106c3758c8cb0c19b09799970440501fde02 source 3f64e7c16a63fdc330e108cd74182c615d229bb6 source 4c3cea26b84cc70a67ff4eda99b842d8786a3628 source 256c5c3f28ef70b70d38e2e07dfca4baab654612 source 57656eb1fae5ae6c4d3b7542a385a93ff434e4e7 source 49524c6dcf04b9dadef8d2b084cf26abcf70b8a9 source 826143684d2697a8620373dce18fa5f24332d5cb source d8305248f687ffa522b56955508d82d60ad5b8c6 source a74efa665c8199899cd778900de686e2b8710fee source e6e8a060ecc6e4fd51cfe88e00d841d546ed5915 :040000 040000 ad77b1a03396af9c8460d94e13cf1c28e5bf54bc dbf71bf6a72509169933f08eb57842c37a266627 M instdir
Created attachment 136948 [details] Example file
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=e6e8a060ecc6e4fd51cfe88e00d841d546ed5915..9b4abcd1c45a646a1ac9120fe1c489ba6bb44e95
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
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
@Xisco Would you mind to do a bisect based on comment 5?
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)
Setting to Win only, no repro with Linux
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)
@Jmux Hoping you might be interested in this one :-)
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.
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
(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/
(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 :-)
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 134818 has been marked as a duplicate of this bug. ***
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still the same (or even a bit more sluggish compared to the stock 6.0.7 on my old Ubuntu 18.04) in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 27892a5e12dada80226f778ab2bd14b1bdaab58a CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded