Overhead associated with OutputDebugString in release build

Question

Is there a significant overhead associated with calling OutputDebugString in release build?

Answer 1

Measured - 10M calls take about 50 seconds. I think it's significant overhead for unused functionality.

Using a macro can help get rid of this in release build:

#ifdef _DEBUG     #define LOGMESSAGE( str ) OutputDebugString( str ); #else     #define LOGMESSAGE( str ) #endif 

Not only removes the calls, but also the parameters evaluation and the text strings are entirely removed and you'll not see them in the binary file.

Answer 2

I'm writing this long after this question has been answered, but the given answers miss a certain aspect:

OutputDebugString can be quite fast when no one is listening to its output. However, having a listener running in the background (be it DbgView, DBWin32, Visual Studio etc.) can make it more than 10 times slower (much more in MT environment). The reason being those listeners hook the report event, and their handling of the event is done within the scope of the OutputDebugString call. Moreover, if several threads call OutputDebugString concurrently, they will be synchronized. For more, see Watch out: DebugView (OutputDebugString) & Performance.

As a side note, I think that unless you're running a real-time application, you should not be that worried about a facility that takes 50 seconds to run 10M calls. If your log contains 10M entries, the 50 seconds wasted are the least of your problems, now that you have to somehow analyze the beast. A 10K log sounds much more reasonable, and creating that will take only 0.05 seconds as per sharptooth's measurement.

So, if your output is within a reasonable size, using OutputDebugString should not hurt you that much. However, have in mind a slowdown will occur once someone on the system starts listening to this output.