If serviceability debugging routines are used in an application, one of three different things can happen to any given debugging routine at runtime:
· The routine is called, and its output is generated (because the debug level associated with the message has been enabled).
· The routine is called, but its output is not generated (because the debug level associated with the message has been disabled).
· The routine call is not present in the application code because serviceability debugging has been compiled out (DCE_DEBUG was not defined when the application was compiled).
Note that, even if a certain debug level has been disabled, any routine or macro call to output a message with that level will still be executed unless other steps are taken to prevent this. The performance cost associated with such "smothered" calls will usually be insignificant, but situations can occur in which this will not be so.
For example, developers should understand the implications of supplying function calls as arguments to serviceability debug output routines (such as DCE_SVC_DEBUG). If the debug code is compiled in (that is, if DCE_DEBUG is defined), then the parameterized function calls will always be executed because the output routine itself will still be called - even though it will produce no output.
In situations like this, the desirable course of action is simply to not call the output routine at all if the currently set debug level has turned it into a no-op. This can be done by using the DCE_SVC_DEBUG_ATLEAST macro to check the current level, as shown in the following example:
if (DCE_SVC_DEBUG_ATLEAST(hel_svc_handle, hel_s_main, svc_c_debug3))
{
DCE_SVC_DEBUG((
hel_svc_handle,
hel_s_main,
svc_c_debug3,
" a_function_call( ) return value is: %s",
a_function_call(parm, status)));
}
The normal performance cost of a serviceability logging operation normally amounts to one mutex lock and (usually) one file lock access per operation.