Overhead associated with OutputDebugString in release build

Question

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

Answer 1

Never leave OutputDebugString() calls in a release build. Always either remove them by using #ifdef statements, or provide another switch to have them turned off.

If you leave them in, have them disabled by default and only activate them on request, because otherwise your app will make it hard to debug other apps which behave nice (i.e., only output debug data on request).

Theres DebugView to catch the output of apps, but of course that's only good if not every app chatters along for no good reason.

Answer 2

The existing answers are dating back to 2009 / 2010.

While the performance of a forgotten OutputDebugString() may not have changed much, I can tell that the tooling makes a huge difference.

• No tool: 30 µs/call (x86) 10 µs/call (x64)
• DebugView (completely disabled): 64 µs/call (x86) 37 µs/call (x64)
• DebugView++ (paused): 67 µs (x86)
• DebugView (autoscroll deactivated): 735 µs/call (x86) 703 µs/call (x64)
• DebugView++ (autoscroll deactivated): 67 µs/call
• DebugView (autoscroll active): 936 µs (x86) 799 µs/call (x64)
• DebugView++ (autoscroll active): 67µs/call
• VS 2019: 81 µs/call
• DebugView (synchronizing 2 instances): up to 1736 µs/call
• DebugView++ (synchronizing 2 instances): up to 102µs/call

Conclusions:

The original DebugView was so slow that I reduced the number of samples to actually finish somewhen.

DebugView++ does a really great job.

VS 2019 seems to do a much better job that older Visual Studios, mentioned in this answer. I can't compare myself, but it's so close at DebugView++ that I consider it really good.

---

Measurements: 100.000 calls of OutPutDebugStringW in a single for loop. All builds in Release mode. Intel i7-6820HQ, 2.7 GHz, limited to 99% to prevent Turbo Boosting. Using std::chrono::high_resolution_clock::now() for measurement before and after the 100.000 calls.

Answer 3

I had read in an article that OutPutDebugString internally does few interesting things:

1. Creates\Opens mutex and wait infinitely till mutex is acquired.
2. Passes the data between the application and the debugger is done via a 4kbyte chunk of shared memory, with a Mutex and two Event objects protecting access to it.

Even if the debugger is not attached ( in release mode) there is significant cost involved in using OutputDebugstring with the usage of various kernel objects.

Performance hit is very evident if you write a sample code and test.

Answer 4

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.

Answer 5

I've not seen a problem in dozens of server-side release mode apps over the years, all of which have built-in metrics. You can get the impression that it's slow because most of the debug-catcher applications you can find (DBWIN32 et al) are pretty slow at throwing the data up onto the screen, which gives the impression of lag.

Of course all of our applications have this output disabled by default, but it is useful to be able to turn it on in the field, since you can then view debug output from several applications, serialised in something like DBWin32. This can be a very useful debugging technique for bugs which involve communicating applications.

Answer 6

Why not measure it yourself? Compile the following code, run it & time it. Then remove the call to OutputDebugString, recompile and rerun. Should take abut three minutes of you time.

   #include <windows.h>

    int main() {
        const int COUNT = 1000000;
        int z = 0;    
        for ( unsigned int i = 0; i < COUNT; i++ ) {
            z += i;
            OutputDebugString( "foo" );
        }
        return z;
    }