is Console.WriteLine a bottleneck in Windows Applications?

Question

If I have WPF application and for debugging purposes there are messages that are being displayed on the console. Will this affect the performance of the application when its configured as a Windows Application and no console is being displayed?

Answer 1

The real bottleneck in Console.WriteLine() is in actually writing to the console. Which is really expensive, particularly when the console needs to be scrolled. There is also considerable overhead in the Visual Studio hosting process capturing the output when there is no console and displaying it in the Output window instead.

Neither of which play a role after you deploy your app. But yes, all the method calls are being made and strings are getting formatted, it only falls in the bit-bucket at the last possible moment when the Windows api function finds out there is no console.

If your app has acceptable perf now, when running in the Debug build, then don't worry about it. If you see less than stellar perf in the Release build without a debugger and you think that it might be caused by Console.WriteLine() then don't hesitate to Search+Replace it to Debug.Print().

Answer 2

A bottleneck implies that it is the slowest point in your code. We can't know that unless we know everything else you're doing.

Is there any performance impact at all, yes, probably. It's not doing nothing, it is doing something. Is it going to be enough to be the bottleneck for your program, I highly doubt it. Is it going to be enough to even have a noticeable impact, it's possible, but unlikely. It all depends on what else your program is doing, and how much you're writing to the console (It would need to be quite a lot for you to start noticing the time it takes.)

As was mentioned in the comments, you could use Debug.WriteLine rather than Console.WriteLine so that you can see the output when debugging, but when you compile the Release build it won't print those statements.

Answer 3

Doing something always takes longer than doing nothing.

The act of writing text to a null console shouldn't be a major performance hit, but what you are passing in as parameters, and in what volume, could be.

Measure the actual performance with and without your console output to see for yourself whether your use pattern is within your acceptable tolerances.

Debug.WriteLine() could be a better choice depending on your requirements, since these will automatically be excluded when you build for Release.

Answer 4

Trying to build and optimize your own logging framework is rarely the best approach.

Have you looked at something like log4net? You can configure various appenders, including logging to the console. You can also build async appenders to really decrease the logging overhead.

Erick