[Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[René J. V. Bertin]

Thiago Macieira wrote:


> It makes QTimer possible.
..
> That sounds quite important to me :-)

I guess so :) I still don't get what purpose calling QObject::timerEvent() has 
if the method itself does nothing. Gives me something to ponder.


> function, because it would break the existing code. And we can't make it a
> single shot because it would be even worse: it would silently would equally
> break existing code that expects the timer to repeat itself. This code is

You're making me doubt. If some class inheriting QObject provides its own 
QFoo:timerEvent() as I understand it should, QObject::timerEvent() isn't called, 
right? Is there code that makes that call explicitly?

> Most won't. How do you choose which ones should get the feature? If you're
> arguing for a white list, please compile such al ist, including all uses in
> KDE code, all applications, etc.

No, I'm not. I think I misread some replies as a suggestion the timer feature 
could maybe be removed. 

> And how would we even achieve this? The only way I can think of is to make
> those functions private (a Qt 6 change) and add the whitelisted classes as
> friends.

What's to stop you (in some future Qt major version) from moving the timer 
features to a dedicated QObjectTimer class, forcing code that relies on the 
feature to inherit that class in addition to QObject?

> Ok, so you found by git bisect (or similar) action. I was hoping you had some
> interesting way of debugging that the problem is timers constantly firing. I

Sadly, no. A boring way:

QCocoaMenu::timerEvent(...)
{
    qInfo() << $somethingSnarky;


I did try monitoring the process with Instruments but that failed to attach.


>> Indeed, I wondered about that, and then let it pass because the compiler
>> will probably optimise it away.
> 
> it won't, because the QBasicTimer object needs to be stored somewhere. If
> you're replacing an int m_timerId with QBasicTimer, there's no overhead. But
> if you don't store the timer ID, there's an overhead.
> 
> You can't not store the QBasicTimer (pardon the double negative). On its
> destruction, it will stop the timer. So if you used it in a regular function
> scope, the tiemr would never fire.

Erm, I was clearly distracted earlier (note to self: discussing Qt concepts 
doesn't mix with Dolly Parton 8-) ).
I thought I'd seen that QCocoaMenu::timerEvent() did something like

 int timerId = e->timerId();
 if (timerId == m_updateTimer) { //etc }

and that the temp. variable was the cause of the overhead you mentioned.

Sorry for the noise.

R.