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

[Ben Lau]

On 23 April 2016 at 00:34, Alejandro Exojo <suy at badopi.org> wrote:

> 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
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>


As long as the passed data is an implicit sharing class like QByteArray,
then it will be fine. Because only a pointer to the contained data is
passed. Data copying only happen when a function write to an implicit
sharing class.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160423/e7709204/attachment.html>