Debug compiling vs. Release compiling

[Patrick Robertson]

Still on the subject of speeding Quicksilver up, I've come across something else that seems like it may slow QS down quite a bit:

There are plenty of if(DEBUG) and if(VERBOSE) statements in the code for when we're debugging.

These to me look like they're compiled into the RELEASE version of Quicksilver. What this means is that the release version of Quicksilver is checking those ifs (which are obviously set to 0) during execution.

Correct me if I'm wrong, but shouldn't the if statements be changed to:

#ifdef DEBUG

          // debug code

#endif

and the same for VERBOSE.

This'll mean the debug/verbose (there are 10 defined in QSDebug.h) code will ONLY get compiled for the cases where we're debugging (i.e. building the debug target) and not for the release.

I just wanted to make sure I'm right on this before I change any of the code - there are a lot of if(DEBUG)s out there, so I don't want to change them all and have it not be worthwhile!

[Patrick Robertson]

Just as an example of where I think this is really wasteful:

Check out line 625 of QSLibrarian.m onwards.

an NSDate, int, float and global float (searchSpeed) are all created and never used in a release version of QS. They should all go inside some #ifdef DEBUG #endif compiler statements.

[Patrick Robertson]

In fact, that list of objects (an NSDate, an int, and a float) are created for every letter pressed in the 1st/3rd panes. And they're never used in a release (or non-verbose) build of QS.

Seems pretty wasteful, no?

[Rob McBroom]

On May 17, 2011, at 11:03 PM, Patrick Robertson wrote:

> In fact, that list of objects (an NSDate, an int, and a float) are created for every letter pressed in the 1st/3rd panes. And they're never used in a release (or non-verbose) build of QS.
>
> Seems pretty wasteful, no?

Very, and that’s an important area. I don’t know enough about the syntax to know if your theory of how to disable this code is correct, but if you “Build & Debug” using the release configuration, could that verify that this code is skipped altogether with your proposed changes? Or does that enable the debug flag automatically. There’s always NSLog. ;)

If it turns out you’re right, I’d say just add the changes to another commit on your speed branch.

--
Rob McBroom
<http://www.skurfer.com/>

[Patrick Robertson]

>  Or does that enable the debug flag automatically. There’s always NSLog. ;)

Turns out (by using NSLog) the DEBUG var is always 1 - so it's included for release code.

I don't think this should be the case, and I'm not sure on how to make it 0 for the release build. (It uses NSDebugEnabled)

[Patrick Robertson]

OK. Seems like all the debug vars are defined at runtime within QS (e.g. see QSApp.m:25) except the DEBUG one - which defines all others.

My proposition is this: There be no debugging in the release version. If you want to debug, you need to build the debug version and set 'DEBUG' to 1 (wherever this is done)

[Patrick Robertson]

If nobody has any objections, here's what I'm about to do (am actually half way through doing:

1. Add a DEBUG = 1 preprocessor macro to the Debug target

2. Remove the QSDebug.h DEBUG definition, and wrap everything else in #ifdef DEBUG #endif

3. Replace every if(DEBUG) with #ifdef DEBUG so they only get compiled if you're in the debug target

[Patrick Robertson]

...phew! With the changes I've made so far, the release build of QS is 20kB slimmer!

[Florian Ludwig Heckl]

Hi Patrick,

> My proposition is this: There be no debugging in the release version. If you want to debug, you need to build the debug version and set 'DEBUG' to 1 (wherever this is done)

I generally agree on this, too. What we lose is the ability to tell a user (with problems) to set some of the variables on the command line before starting QS and give us the log output for analysis so we can see if it's a general problem or user-specific. But then again, we could provide that user a special debug build in such situations...

Kind regards,
Florian

[Patrick Robertson]

> But then again, we could provide that user a special debug build in such situations...

Yep. I think that's probably the way to go. To be honest, we haven't been using the console logs with users at all. Probably a good idea for us to start :)