Efficiency Considerations

Various events have varying degrees of overhead in respect to the execution time of the program being debugged. Some events, like the simplest breakpoints, have practically no overhead. Events based on a single breakpoint have minimal overhead.

Multiple breakpoints, such as inclass, that might result in hundreds of breakpoints, have an overhead only during creation time. This is because dbx uses permanent breakpoints; the breakpoints are retained in the process at all times and are not taken out on every stoppage and put in on every cont.

In the case of step and next, by default all breakpoints are taken out before the process is resumed and reinserted once the step completes. If you are using many breakpoints or multiple breakpoints on prolific classes the speed of step and next slows down considerably. Use the dbxenv step_events to control whether breakpoints are taken out and reinserted after each step or next.

The slowest events are those that utilize automatic single stepping. This might be explicit and obvious as in the trace step command, which single steps through every source line. Other events, like the watchpoints stop change expression or trace cond variable not only single step automatically but also have to evaluate an expression or a variable at each step.

These are very slow, but you can often overcome the slowness by bounding the event with a function using the -in modifier. For example:

trace next -in mumble
stop change clobbered_variable -in lookup

Do not use trace -in main because the trace is effective in the functions called by main as well. Do use in the cases where you suspect that the lookup() function is clobbering your variable.