Adding signals/slots (QObject functionality) to QGraphicsItem: performance hit?

[tiftof]

I want to add signals/slots to a QGraphicsItem so I can reach QGraphicsItemObjects from another thread. There are two options that I know of: use QGraphicsObject or inherit from QObject and QGraphicsItem.

Using QGraphicsObject
This is assumed to be slow. According to this answer on stackoverflow QGraphicsObjects are slow because of their implementation. When I look in the source of QGraphicsObjects I can see a lot of signals being emitted according to changes made to the object. To me this seems a plausible argument for why QGraphicsObjects are slow, but I think this performance hit (if it really is one) can be avoided by the second solution.

Inheriting from QObject and QGraphicsItem.
When constructing a class that inherits from QObject and QGraphicsItem it seems that you get the most interesting feature of QGraphicsObject minus the performance hit: you are able to define slots and emit signals in your class but you don't inherit the default implementation of QGraphicsObject that would constantly emit signals on changes you might not be interested in. You are now able to emit signals but don't have to worry about signals being emitted for things you don't care about (x value that changes emits a signal in QGraphicsObject but not in this solution).

Summary of my question

• Are QGraphicsObjects really slower than QGraphicsItems?
• If they are, is it because the implementation emits signals (and emitting signals is a
  big performance hit)?
• And if so, does the second solution (multiple inheritance) avoid this penalty?

[franz]

I can only give a general answer to this. I haven't done any benchmarking on this one. Emitting signals (basically calling the signal function) takes time. It runs through the connected signals and slots and executes those immediately when the connection is direct. Signal-slot connections are string based, so string comparison is involved and may have an impact. So there are some things that may influence speed here. The most significant of those is hard to pin-point. I'm pretty sure the Trolls have improved the speed in their slot discovery to the point where not much speed is to be gained. However, depending on the implementation, the length of the signal & slot names and the amount of arguments may or may not have an impact. When using direct connections, the execution speed of the directly connected slots called as a result of the signal emission is also significant -- they are executed serially and immediately.

Does the second solution then avoid this penalty if you provide equally named signals and emit them at the same rate? No.

The real question is of course where the performance hit is coming from. A proper profiling session has to be done to determine this.