[cacarr1]

Though most of us with a decent sense of humor think all those debug code and snappiness jokes stopped being funny back in 2000...I wonder if someone could explain what debug code really is?
Is there even such a thing?
If so, what could it do to an OS's overall performance?
Or is this just the techno-geeks version of Snape hunting (those in the Midwest have probably heard of this)?

Just curious...
thanks.

BTW, seriously guys, your 'snappiness' and debug code jokes are really not funny.
Seriously.

[SoBayJake]

Debug code is code that is inserted into the actual code to provide the developer helpful information in tracking down problems.

It could be doing any of a number of things...logging things to disk (slow), keeping track of special variables, memory locations, doing extra checks to make sure parameters are correct, etc.

In the case of Mac OS X, I have no idea what they might be doing.

Usually (at least in the work I've down) debug code is stripped out or compiled out of the actual code. However, the code in Mac OS X could still be in there, but without the presence of certain environment variables, the code does not do that much.

If there is unnecessary debug code, it would slow things down. How much is slows things down depends on what it is doing, and how much it is doing.

[Krusty]

Originally posted by cacarr1:
.I wonder if someone could explain what debug code really is?
Is there even such a thing?

Well ... there is actually a such a thing. Basically its typically "extra" code that doesn't really perform a task other than testing the "real" code. It can slow down a program because, at various times (whenever the program encounters "debug code"), it will "waste time" going thru procedures that don't really affect how the program works from the end-user perspective but simply provides feedback to the programmer.

Also, debug code (any code really) can be put in to a program in a way that it can be "turned on" and "turned off" without changing the actual lines of source code -- so that a "debug version" and a "non-debug version" could have identical source code. HOWEVER, when the source code is actually compiled (made into an application) the resulting application WILL NOT be the same. NO WAY to have a "7B85" and a "7B85 with debug code removed" -- they would simply NOT result the same finished product as one would incorporate the debug code and the other would not. The resulting applications would be entirely different (checksum would differ, size would most likely differ, etc.) even if they appeared to act the same from the end user perspective .

hmmm ... I feel like I'm making this more complex rather than explaining anything. I'll stop now.

[Arkham_c]

Originally posted by cacarr1:
Though most of us with a decent sense of humor think all those debug code and snappiness jokes stopped being funny back in 2000...I wonder if someone could explain what debug code really is?

Well, aside from print statements, debug code generally refers to debugging symbol tables in a binary. It's not really "code" per se.

Debug code in this sense is created by passing debug flags to the compiler when compiling. In old-school compilers, the debug flags and the "optimize" flags were mutually exclusive, that is, turning on the debug flags disabled the optimize flags. Hence, debug code was slower.

With the GCC on OSX you can have debug on (-g) and optimize on (-On, where n=1,2) together. Typically debug code built with gcc is LARGER than non debug code, but it's not necessarily significantly slower. All the same, a production build will generally be compiled with -O2 and not -g.

[cacarr1]

thanks guys...

[cacarr1]

thanks guys...

[CatOne]

Originally posted by Arkham_c:
Well, aside from print statements, debug code generally refers to debugging symbol tables in a binary. It's not really "code" per se.

Debug code in this sense is created by passing debug flags to the compiler when compiling. In old-school compilers, the debug flags and the "optimize" flags were mutually exclusive, that is, turning on the debug flags disabled the optimize flags. Hence, debug code was slower.

With the GCC on OSX you can have debug on (-g) and optimize on (-On, where n=1,2) together. Typically debug code built with gcc is LARGER than non debug code, but it's not necessarily significantly slower. All the same, a production build will generally be compiled with -O2 and not -g.

Well... not QUITE true, as assert statements (or the ASSERT macro) is code that does some sanity checks, and if the "assertion" isn't true, the program will exit with an assertion error. This is very helpful in application development... to make sure the program at a state in time is behaving as it should be. Assert statements can make debugging a LOT easier.

Assert statements are automatically stripped from an application when you build it as "release." The compiler does this -- the developer doesn't need to worry about anything, the asserts stay in the source code.

But building as "release" or "debug" is an all-or-nothing proposition for an executable, so the chances of this code being in the final release are slim-to-none. Now that being said, I have seen "assertion failures" in some Windows binaries that were purportedly release builds... oops

[arekkusu]

What was said above is correct but there is more to it. "Debug code" includes:

1) runtime assertions of error conditions, to help programmers catch bugs. This includes NSAssert, NSLog, etc.
2) non-optimized code. By default development builds are compiled with optimization turned off so that the programmer can more easily step through functions in the debugger. Deployment builds are compiled with optimizations turned on.
3) debugging symbols. Related to, but separate from 2), these are the human-readable names of each function in a compiled application. You can mix and match optimization and symbols.
4) debugging resources, for example the info and classes file inside a .nib. These are only needed during UI layout, not at runtime.

Now, most of the people complaining about "debug code" are either joking or just don't know anything about software engineering.

Obviously, releasing software with any of the above "debug code" in it is less than optimal. There are speed and space hits for all four types, although 1) is extremely minimal. 2) is the worst. 3) and 4) just waste disk space.

Of course, Apple removes 2) and 3) for everything they ship. 1) and 4) are sometimes left in, and NOT ALWAYS ON PURPOSE. Go look inside iCal's resources-- all the nibs are stripped of debug resources. Now go look at iPhoto-- how many megabytes of disk are being wasted there?

[Truepop]

Originally posted by cacarr1:
Though most of us with a decent sense of humor think all those debug code and snappiness jokes stopped being funny back in 2000...

But I thought OS X and the jokes came in 2001.