6
votes

I currently have a hierarchy of items based off of QGraphicsItem.

I want to move to QGraphicsObject instead so that I can put properties on my items. I will not be making use of signals/slots or any other features of QObject.

I'm told that you shouldn't derive from QObject because it's "heavy" and "slow".

To test the impact, I derive from QGraphicsObject, add a couple properties to my items, and look at the memory usage of the running app. I create 1000 items using both flavors and I don't notice anything more than 10k more memory usage.

Since all I am adding on to my items are properties, is it safe to say that QObject only adds weight if you are using signals/slots?

2

2 Answers

3
votes

I think it depends on what you mean by weight. If you're not worried about the additional memory required nor all the extra methods and things that come with QObject, which sound like baggage in your case, then yes.

But, if all you need is a way to store some additional information, why not subclass QGraphicsItem and add a method or two that allow you to store the necessary data? By doing so, I think you'll better communicate the intent of your code, which seems more important than all of the above.

0
votes

How about performance? There is extra cost in QGraphicsObject when calling setX/setY, and so on. You can go to QGraphicsItemPrivate::setPosHelper and find more details.