[Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
René J. V. Bertin
rjvbertin at gmail.com
Wed Aug 30 23:17:05 CEST 2017
Thiago Macieira wrote:
Oops, missed this one.
> Unfortunately, we can't change anymore.
Can someone explain what could possibly be broken by changing this? Can the
current base-level QObject::timerEvent() be used for anything constructive other
than heating the office or preventing a CPU core from going to sleep?
I only made my suggestion because it seemed rather evident that anyone using the
QObject timer would override the timerEvent() method.
That said, it does seem a bit overkill to give each and every instance
inheriting QObject timer features. Most will presumably never use that in a
typical application, would they?
>> It took me an unreasonable amount of time trying to figure out the reason
>> for the burning, the fact that QCocoaMenu::timerEvent() could be being
>> called as fast as possible and for nothing occurred to me only after trying
>> all other possibilities. And I knew only the timer change could be the
>> culprit; I can only imagine how much more time I'd have spent if this bug
>> had been latent for a few months.
>
> i'm glad you found it.
>
> How did you?
How did I discover the issue? I have a top-of-the-2011-line laptop i7 in a 13"
MBP, and no airco. One tends to notice when it gets busy and remains busy when
you're not expecting it, and you know something's wrong when a quick look in
`top` shows nearly 100% CPU for an application that appears to be doing nothing
(KDevelop in this case, and fortunately I discovered afterwards that Assistant
worked as a demonstrator too).
Found the bug/fix? The usual way, reverting all changes and restoring them in
order of least likely culprit. Then by generating trace output, evidently I
thought last of putting it *before* the timer ID check, and then I had to
consult the docs to confirm that one indeed needs to kill the timer when done.
I'd never have guessed that a noop event handler callback could have pump this
many resources.
> Actually, there is an overhead, albeit very small one: the timer ID is stored.
Indeed, I wondered about that, and then let it pass because the compiler will
probably optimise it away.
R.
More information about the Development
mailing list