如果我有WPF应用程序并且出于调试目的，控制台上会显示消息。当它被配置为Windows应用程序并且没有显示控制台时，这是否会影响应用程序的性能？
答案 0 :(得分：6)
Console.WriteLine（）的真正瓶颈在于实际写入控制台。哪个真的昂贵，特别是当需要滚动控制台时。当没有控制台并在“输出”窗口中显示输出时，Visual Studio托管过程中捕获输出的开销也相当大。
在部署应用后，这两种方式都不起作用。但是，是的，正在进行所有方法调用并且字符串正在被格式化，它只会在Windows api函数发现没有控制台的最后可能时刻落在位桶中。
如果您的应用现在具有可接受的性能，则在Debug构建中运行时，请不要担心。如果在没有调试器的版本构建中看到不太明星的性能，并且您认为它可能是由Console.WriteLine（）引起的，那么请不要犹豫，将其替换为Debug.Print（）。
答案 1 :(得分：2)
瓶颈意味着它是代码中最慢的一点。除非我们知道你正在做的其他事情，否则我们无法知道。
是否有任何性能影响，是的，可能。它没有做任何事情，它正在做某事。是否足以成为您计划的瓶颈，我对此表示高度怀疑。它是否足以甚至产生明显的影响，这是可能的，但不太可能。这一切都取决于你的程序正在做什么，以及你写多少钱给控制台（你需要花很多时间才能开始注意它所花费的时间。）
正如评论中提到的，您可以使用Debug.WriteLine而不是Console.WriteLine，以便在调试时可以看到输出，但是当您编译Release版本时，它将不会打印这些语句。
答案 2 :(得分：0)
做某事总是比什么都不做要长。
将文本写入空控制台的行为不应该是主要的性能损失，而是作为参数传递的内容以及可能的卷。
使用和不使用控制台输出测量实际性能，以便亲自了解您的使用模式是否在您可接受的容差范围内。
Debug.WriteLine（）可能是更好的选择，具体取决于您的要求，因为在为Release构建时，这些将自动排除。
答案 3 :(得分：0)
尝试构建和优化自己的日志框架很少是最好的方法。
你看过像log4net这样的东西吗？您可以配置各种appender，包括登录到控制台。您还可以构建异步appender以真正减少日志记录开销。
埃里克