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' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
