Is Console.WriteLine a bottleneck in Windows applications?

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

+7
source share
4 answers

The real bottleneck in Console.WriteLine () is actually written to the console. Which is really expensive, especially when you need to scroll through the console. In addition, there is significant overhead during the hosting process of Visual Studio, as a result of which there is no output when the console is not displayed and is displayed in the output window.

None of them matter after deploying your application. But yes, all method calls are made and the lines are formatted, they only get into the bit bucket at the last possible moment when the Windows api function detects that the console is missing.

If your application now has acceptable performance when running in the Debug assembly, do not worry about it. If you see less than the stellar perf in the Release assembly without a debugger, and you think this might be caused by Console.WriteLine (), feel free to look for + replace it with Debug.Print ().

+5
source

The bottleneck implies that this is the slowest point in your code. We cannot know that if we do not know everything else that you do.

Is there any performance impact, yes, probably. He does nothing, he does something. It will be enough to be a bottleneck for your program, I doubt it very much. This will be enough to even have a noticeable impact, it is possible, but unlikely. It all depends on what else your program is doing and how much you write on the console (you should have a lot before you can notice the time it takes.)

As mentioned in the comments, you can use Debug.WriteLine , not Console.WriteLine , so you can see the result when debugging, but when you compile the Release assembly, it will not print these statements.

+2
source

Doing something always takes more time than doing nothing.

The act of writing text to an empty console should not be a serious blow, but what you pass as parameters, and to what extent it can be.

Measure actual performance with and without console output to ensure that your usage pattern is within your acceptable tolerances.

Debug.WriteLine () may be the best choice depending on your requirements, as they will be automatically excluded when created for release.

0
source

Trying to create and optimize your own logging structure is rarely the best approach.

Have you watched something like log4net? You can configure various applications, including logging in the console. You can also create asynchronous applications to really reduce the cost of logging.

Eric

0
source

All Articles