17

I recently posted a question about the overhead of QObject in typical usage scenarios, but unfortunately the question got closed as a duplicate of another question that didn't technically answer the question.

What is worse, the hasty "Samaritans" who politely rushed to close my question interrupted the answer I was just finishing typing after running a few tests. Since I can no longer post my findings in my original question, I'll post it here so it is available to others who might need that information.

dtech
  • 47,916
  • 17
  • 112
  • 190
  • 11
    The rushing to mark everything as a duplicate around here drives me completely insane. It's the reason I rarely post here anymore. You would think that programmers would understand that a generic, general answer *may not apply* to a specific question. Your question/answer was *exactly* what I was looking for, **NOT** the one that everyone said answered your question. Thanks for posting this! – Freedom_Ben Apr 30 '14 at 19:07
  • 1
    Thanks for the post as well! I think people who close down other topics that are doing so incorrectly - like in your case, should get a 1-week long ban. Maybe after some time, they stop spamming the close button on everyone's post. Just like excessive posting gets ur banned, excessive closing down posts should get u banned to. – Dariusz Nov 04 '18 at 13:19

1 Answers1

18

A lot of people have hinted at QObject being heavy, but without any clarity on how heavy is it exactly. So I did some measurements, not very accurate, all values are approximate.

  • unused QObject ~160 bytes
  • single auto connection w/o arguments ~235 bytes
  • 2 auto connections w/o arguments ~315 bytes
  • 3 auto connections, 1 with 3 arguments ~400 bytes
  • 2 auto connections, 1 queued with 3 arguments ~432 bytes

Those numbers should take into account I am using a 64 bit Qt build.

So, in conclusion, the overhead of QObject is quite significant indeed. Nothing to sneeze at or overuse.

dtech
  • 47,916
  • 17
  • 112
  • 190
  • I think it would be better if you just add this answer to http://stackoverflow.com/questions/1274022/getting-the-size-of-a-qt-object and delete this question (or flag moderator for merging). I'll make a point of going to upvote it there if you do :-) – hyde Apr 04 '13 at 14:21
  • And while you are at it, maybe tell what platform (OS, compiler version, 32/64 bits) those are measured, as that will certainly affect the result. – hyde Apr 04 '13 at 14:26
  • @hyde - the most relevant thing is that the build is 64 bit and it is mostly due to ints and pointers, which I mentioned. I don't think the rest will have significant differences in size. Still, the OS is Windows 7 64bit and the compiler is MSVC2012 – dtech Apr 05 '13 at 01:01
  • 1
    @ddriver please don't move this question. It is much more helpful here because it is a lot easier to find. In my shop the question of `QObject` overhead comes up a lot whenever we subclass. It is important to know. – Freedom_Ben Apr 30 '14 at 19:12
  • *@dtech* - I have no idea how you have tested this. Can you check, if those values are still up-to-date? – derM - not here for BOT dreams Oct 24 '18 at 07:57
  • @derM I created batches of objects and polled the system for the memory usage of the process, calculating the increase of memory usage against the increase of object count. I don't have that code anymore to rerun unfortunately, but I don't expect this to have decreased, if anything it might have increased. Also, creating qml context aware qobjects for use in qml has significant additional overhead. – dtech Oct 24 '18 at 11:56
  • @dtech it will be great if you can give insights on how this was measured. – Kamath Aug 18 '21 at 07:22