LEICHTER-JERRY@YALE.ARPA.UUCP (01/16/87)
We're about to finish an application system, which is 90% coded in C.
During development, we've naturally compiled /DEBUG/NOOPT. During initial
use, we want the speed of /OPTIMIZE, we can do without the debugger, but
if (or when) it does crash, it's pretty hard to do without the traceback
to tell us at least where.
What does /DEBUG=TRACEBACK cost us in term of speed. The C manual
tells me that the optimizer will omit some stuff if /DEBUG is specified,
but I don't have any clue as to how much that might cost. And does
the traceback inclusion cost us speed, i.e., does it generate extra
instructions that keep track of where the PC is in each module?
LINK/DEBUG=TRACEBACK includes a symbol table of global symbols in your image;
it has NO other effect on the image, and no effect at all on its speed. (In
fact, /DEBUG in the Linker just adds a bigger symbol table; it has an effect
on image activation time, because the image will come up in the Debugger, but
if all you do at the Debugger prompt is type GO, the image will run at the
same speed as it normally does.)
In compilers, prior to V4, /DEBUG generally turned off some optimizations.
Starting with V4, the new policy is that qualifiers are independent of each
other. (That's why CC/MACHINE won't show you the machine code - you need
CC/MACHINE/LIST.) Hence, /DEBUG includes extra debugging information - symbol
tables - in the object file, but otherwise has no effect on generated code.
For easier debugging, you'll generally want to use /NOOPTIMIZE with /DEBUG -
some compilers, PASCAL, for example, will even tell you this when you run them
/DEBUG/OPTIMIZE. But you don't have to. (Some compilers also allow you to
turn off some optimizations while leaving others on. In this case, the
documentation may recommend that only particular optimizations be disabled
when compiling /DEBUG.)
-- Jerry
-------