控制台输出(Console.WriteLine)在Windows应用程序中会成为瓶颈吗？

Question

7

如果我有一个WPF应用程序，并且为了调试目的，在控制台上显示消息。当它被配置为Windows应用程序并且没有控制台显示时，这会影响应用程序的性能吗？

该问题的答案是不会影响应用程序的性能，因为在 Windows 应用程序中，控制台窗口并不存在。控制台只是一个命令行工具，用于在控制台应用程序中显示输出信息。在 WPF 应用程序中，可以使用 Debug 类的方法来输出调试信息，而这些信息将不会显示在控制台上，因此不会影响应用程序的性能。

- Nickolay Kondratyev

6

为了调试目的，为什么不使用 Debug.WriteLine 呢？它会输出到“输出”窗口，但是如果我没有记错的话，可以通过 Visual Studio 选项将其重定向到立即窗口。 - erodewald

测量一下，你就会知道了 :-) - Eric J.

类似的问题针对asp.net，不能保证答案相同：https://dev59.com/m3VC5IYBdhLWcg3w9GA9 - Joel Rondeau

4个回答

3

瓶颈意味着它是您代码中最慢的点。除非我们知道您正在做的其他所有事情，否则我们无法知道这一点。

是否有任何性能影响，是的，可能有。它不是什么都不做，它正在执行某些操作。它是否足以成为您程序的瓶颈，我非常怀疑。它是否足以产生显著影响，这是有可能的，但不太可能。这完全取决于您的程序还在做什么，以及您写入控制台的量有多大（您需要写入相当多才能开始注意到花费的时间）。

正如评论中提到的那样，您可以使用Debug.WriteLine而不是Console.WriteLine，以便在调试时可以看到输出，但是当您编译发布版本时，它将不会打印这些语句。

- Servy

0

做事总是比不做事要费时间。

向空控制台编写文本不应该对性能造成太大影响，但您传递的参数及其数量可能会影响性能。

通过比较有和没有输出到控制台时的实际性能，来判断您的使用模式是否在可接受的容忍度范围内。

根据您的需求，Debug.WriteLine() 可能是更好的选择，因为在构建 Release 版本时，这些将自动排除在外。

- dthorpe

0

试图构建和优化自己的日志框架很少是最佳方法。

你看过像log4net这样的东西吗？你可以配置各种附加程序，包括记录到控制台。你还可以构建异步附加程序来真正减少日志记录开销。

Erick

- Erick T

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Hans Passant · Accepted Answer

在Console.WriteLine()中，真正的瓶颈在于实际写入控制台。这是非常昂贵的，特别是当控制台需要滚动时。在没有控制台并将其显示在“输出”窗口中时，Visual Studio托管进程捕获输出也存在相当大的开销。

在部署应用程序后，这两个因素都不起作用了。但是，所有方法调用和字符串格式化仍在进行，只有在Windows API函数发现没有控制台时，才会在最后一刻丢弃它们。

如果您的应用程序在Debug构建中具有可接受的性能，则不用担心。如果您在没有调试器的Release构建中看到低效的表现，并认为可能是由于Console.WriteLine()导致的，则可以毫不犹豫地将其替换为Debug.Print()。