[Development] Let's get rid of qDebug/qWarning/qCritical!

Poenitz Andre Andre.Poenitz at digia.com
Fri Jan 10 14:25:27 CET 2014


Grr... OWA.

> And here are the results:
>
> PASS   : CatLogBench::qWarningPrintf1()
> RESULT : CatLogBench::qWarningPrintf1():
>      0.0010 msecs per iteration (total: 67, iterations: 65536)
> PASS   : CatLogBench::qWarningPrintf2()
> RESULT : CatLogBench::qWarningPrintf2():
>      0.0013 msecs per iteration (total: 90, iterations: 65536)
> PASS   : CatLogBench::qWarningStream()
> RESULT : CatLogBench::qWarningStream():
>      0.0016 msecs per iteration (total: 54, iterations: 32768)
> PASS   : CatLogBench::qCWarningStream()
> RESULT : CatLogBench::qCWarningStream():
>      0.0018 msecs per iteration (total: 59, iterations: 32768)
> PASS   : CatLogBench::qCWarningPrintf()
> RESULT : CatLogBench::qCWarningPrintf():
>      0.0010 msecs per iteration (total: 69, iterations: 65536)
> PASS   : CatLogBench::cleanupTestCase()
> Totals: 7 passed, 0 failed, 0 skipped
>
> So, there is of course some measurable overhead, but I wouldn't
> say it disqualifies the streaming variant per se :)

This indicates an overhead of 30%, or 80%. In core functionality.
While this does not immediately disqualify the approach, there
needs to be some kind of benefit to compensate. 

So far I am not seeing that.

> BINARY SIZE
>
> On to the binary size. I removed the QBENCHMARK macro
> and disassembled the gcc output. Here it shows that QDebug
> is completely inlined, the streaming operator variants do indeed 
> generate a hell lot of instructions !
>
> But since this is quite a bogus metric here are the size increase 
> of Qt5Core with, and without the core.io patch included 
> (again a release non-developer build with gcc 4.8.2):
>
> -rwxr-xr-x 1 kkoehne users 5311213 Jan 10 12:55 libQt5Core.so.5.3.0.original
> -rwxr-xr-x 1 kkoehne users 5357104 Jan 10 12:58 libQt5Core.so.5.3.0_patch
>
> So the overhead is measurable.
>
> Given these concerns, I'd like to propose adding a printf style overload to qCDebug:
>
> https://codereview.qt-project.org/#change,75029
>
> Note the patch is fairly ugly because we're gracefully handling the c
> ase where the toolchain doesn't respect Q_COMPILER_VARIADIC_MACROS, 
> I'll post a second mail about this soon ...

What about post-poning the whoie idea until we can rely on variadic macros?

Regards,
Andre'



More information about the Development mailing list