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

Alejandro Exojo suy at badopi.org
Fri Apr 22 18:34:19 CEST 2016


El Friday 22 April 2016, Nuno Santos escribió:
> 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.

This paragraph in the documentation (same link Benjamin sent) is also pretty 
enlightening:

> Compared to callbacks, signals and slots are slightly slower because of the
> increased flexibility they provide, although the difference for real
> applications is insignificant. In general, emitting a signal that is
> connected to some slots, is approximately ten times slower than calling
> the receivers directly, with non-virtual function calls. This is the
> overhead required to locate the connection object, to safely iterate over
> all connections (i.e. checking that subsequent receivers have not been
> destroyed during the emission), and to marshall any parameters in a
> generic fashion. While ten non-virtual function calls may sound like a
> lot, it's much less overhead than any new or delete operation, for
> example. As soon as you perform a string, vector or list operation that
> behind the scene requires new or delete, the signals and slots overhead is
> only responsible for a very small proportion of the complete function call
> costs. The same is true whenever you do a system call in a slot; or
> indirectly call more than ten functions. The simplicity and flexibility of
> the signals and slots mechanism is well worth the overhead, which your
> users won't even notice.

That was probably written long ago. I've read people mentioning that it might 
be that signal emission would be slower nowadays.

Also, what type are you passing in the signal? The value is copied, so if it's 
expensive to copy, that might be a factor as well. I believe that is one of 
the reasons why APIs like QIODevice don't send the received data through the 
signal, but just the notification of the presence of new data. Later on you 
have to retrieve it.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net



More information about the Interest mailing list