On 23 April 2016 at 00:34, Alejandro Exojo <s...@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@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.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
