Hello,
I found there is some strange behaviour with Timers.
In my project I use only one Timer. And it is in AudioProcessorEditor so as I understand it should work only when my plugin window is opened. And by debuging I found it works as I expect.
But in the Debug Navigator in xCode, under CPU usage I see many timers. Ok, it’s still understandable for me - probably there are more timers in the depth of Juce framework code.
But what is strange for me, two things:
- I can’t see there my
Timer;
- And - wthat is most strange for me - there is one timer which starts running only after second opening of my plugin window. I mean it doesn’t work when I launch my plugin and open window. It doesn’t work when I close it. And suddenly it start works when I open window again. And from that point (I mean second window opening) it is always running on each windows opening.
It looks like that:
And of course after first open, my Timer works great, it’s just not shown on that window.
It wouldn’t for me big deal, but the problem is my plugin CPU usage is almost doubled when that strange timer start running.
I thought maybe my first timer doesn’t stop running on closing window, so debuger run new instance of Timer every time I open window. But at first, why then that additional Timer is only one and it stops running everytime I close the window. And at second, to be sure my plugin stops timer every time I close the window I call stopTimer() in the destructor of AudioProcessorEditor. But it doesn’t help.
So now, I have no idea how to fix that. But as I told it’s important. Because every time that second Timer starts running the CPU usage jumps almost double - from about 30% to about 55%.
I think what you are seeing there are instances of a HighResolutionTimer (https://docs.juce.com/master/classHighResolutionTimer.html) these run on an independent thread for improved accuracy at the cost of launching and running a new thread. The normal Timer class has it’s callback called from the main message thread.
OK, but how to deal with that? Can I turn it off in some way for optimizing?
Of course I am still in debug mode. I am not sure how it looks in release when profiling. But I am worry in advance 
If I can improve something in debug mode, why don’t do that?
The thread name JUCE Timer is used for the shared thread of the normal Timer.
Could you try setting a breakpoint inside the TimerThread() constructor? It’s in juce_Timer.cpp. It should definitely be only called once (when running as a Standalone App), but just to make sure.
Yes, the constructor of TimerThread() is called only once… but:
- I am not running my plugin as a Standalone App, but as a plugin in Juce Plugin Host
- That constructor is called only once when insert plugin in the host, but opening and closing window of plugin (even many times) doesn’t call the
TimerThread() - allthough my Timer is in the AudioProcessorEditor;
- Now I am testing on Windows 10, but the issue I described on the beginning was on the Mac OSX Mojave. Now I can’t test it, but when I back home I will try it.
And - what is most impoortant - what that fact (calling only once TimerThread()) tells me?
What can I do to improve the performance, and get rid the behaviour which I described on the beginning?
All Timers in your process share a single TimerThread. It’s created when the first Timer starts, and isn’t destroyed when you close the plug-in window. I was asking about the constructor, because on the screenshot it looked like multiple TimerThreads might be created, which would be strange.
Maybe someone from the JUCE team can help…
Yesterday I tried to use Apple Instruments to figure it out what’s going on.
But I am quite new in Instruments so it didn’t help me. Probably I need to watch more tutorials about that
But still the most strange thing is that some additional timer starts work only after second and every next window opening.
I thought maybe after release compilation the problem will disappear. But it’s still there, and in Instruments it see it also. But can’t find part of code which starts that timer.
