QT_NO_DEBUG, Q_ASSERT(), and release build types

Andreas Hartmetz ahartmetz at gmail.com
Wed Jan 14 12:32:43 GMT 2009


On Wednesday 14 January 2009 11:15:56 Armin Berres wrote:
> On Wed, 14 Jan 09 02:47, Andreas Hartmetz wrote:
> > I've looked up the #defines and tested it. Removing the !QT_NO_DEBUG
> > condition from kDebug() and setting QT_NO_DEBUG yields the desired
> > result: debug output is enabled, asserts (and therefore some internal
> > checks in Qt) are disabled. The size of libkdeui with -O1 and debug
> > symbols (my usual build setting) was reduced by about 300 kBytes out of
> > ~46 MB, too. I didn't do any performance tests; the differencen is
> > probably small.
> >
> > Any objections to committing this to trunk and/or 4.2?
>
> Don't forget, that you also want to disable debug output (at least for
> release builds) by default in this case. See the two patches in one of my
> other messages.
> I guess because of these changes (little changes though, but no bugfixes)
> this is 4.3 material anyway.
>
Yeah, I guess this is actually 4.3 material.
AFAIK KDE has always shipped with debug output enabled - the more noisy parts 
are usually disabled by runtime configuration. I  would expect some maintainers 
of modules where debug output is helpful in bug reports to be upset if we 
disable it hard. For "my" code I don't care much either way.
If we disable it hard we should try to not only take out the output but the 
generation of the strings to output, too! Output to console is often quite 
slow but generation of debug output is also time-consuming in some cases, e.g. 
for KUrl or simply very long strings. And it's probably a few percent (2?) of 
our binary sizes.
This should be a matter of making the optimizer recognize that the data goes 
nowhere and skip its generation.




More information about the kde-core-devel mailing list