[Interest] Qt signal overhead (same thread, direct connection)

[Benjamin TERRIER]

Hi,

When using a direct connection the call is immediate and does not
depends on an event loop.

>From Qt doc:

"When a signal is emitted, the slots connected to it are usually
executed immediately, just like a normal function call. When this
happens, the signals and slots mechanism is totally independent of any
GUI event loop. Execution of the code following the emit statement
will occur once all slots have returned."
http://doc.qt.io/qt-5/signalsandslots.html

You can see what Qt does by looking at the generated moc files
(moc_object.ccp) and at qobject and qmetaobject.cpp
Basically when you call a signal, the signal will call
QMetaObject::activate(), which will call QMetaObject::metacall(),
which will call qt_metacall() on the receivers.
The only thing that might take time seems to be a mutex lock within
QMetaObject::activate().

Regards

Benjamin

2016-04-22 10:38 GMT+02:00 Nuno Santos <nunosantos at imaginando.pt>:
> Hi,
>
> I have an application that generates real time audio and in a system like
> this, a interruption may cause audio glitches.
>
> Nowadays, in iOS, audio apps can be loaded by other apps. This transition
> takes time and probably some resources too.
>
> While playing my app with the built in arpeggiator and then switching to
> another app, the notes would stop playing for a while, creating a non
> desired break in the flow.
>
> The curious thing is that, if I had a single note playing, the sound was not
> being broken.
>
> Since the sound rendering engine is the same I couldn’t understand what was
> going on.
>
> Then I made an experiment. Arpeggiator was using a signal to send the noteOn
> to the audio render engine. I decided to call the function directly on the
> synth render engine. Guess what, the problem disappears.
>
> Is the signal/slot mechanism tied to the event loop? How much does it take
> for a signal/slot to be called? It might not be significant on a desktop
> computer but it certainly is on a ARM device specially in this kind of
> performance sensitive contexts.
>
> After this, I’m into changing crucial functions to callbacks to improve
> performance. Is there any advice you could give me?
>
> Thanks,
>
> Regards,
>
> Nuno
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>