windows 与发布版本中的 OutputDebugString 相关的开销
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/729435/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Overhead associated with OutputDebugString in release build
提问by Canopus
Is there a significant overhead associated with calling OutputDebugString in release build?
在发布版本中调用 OutputDebugString 是否有很大的开销？
采纳答案by sharptooth
Measured - 10M calls take about 50 seconds. I think it's significant overhead for unused functionality.
实测 - 10M 呼叫大约需要 50 秒。我认为对于未使用的功能来说这是一个很大的开销。
Using a macro can help get rid of this in release build:
使用宏可以帮助在发布版本中摆脱这种情况：
#ifdef _DEBUG
#define LOGMESSAGE( str ) OutputDebugString( str );
#else
#define LOGMESSAGE( str )
#endif
Not only removes the calls, but also the parameters evaluation and the text strings are entirely removed and you'll not see them in the binary file.
不仅删除了调用，还完全删除了参数评估和文本字符串，您将不会在二进制文件中看到它们。
回答by eran
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.
当没有人收听其输出时，OutputDebugString 可能会非常快。但是，在后台运行侦听器（DbgView、DBWin32、Visual Studio 等）会使它慢 10 倍以上（在 MT 环境中更慢）。原因是这些侦听器挂钩报告事件，并且它们对事件的处理是在 OutputDebugString 调用的范围内完成的。此外，如果多个线程同时调用 OutputDebugString，它们将被同步。有关更多信息，请参阅注意：DebugView (OutputDebugString) 和性能。
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.
作为旁注，我认为除非您正在运行实时应用程序，否则您不应该担心需要 50 秒才能运行 10M 调用的工具。如果您的日志包含 10M 条目，那么浪费的 50 秒是您的问题中最少的，现在您必须以某种方式分析野兽。一个 10K 的日志听起来更合理，而且根据尖牙的测量结果，创建它只需要 0.05 秒。
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.
因此，如果您的输出在合理的大小范围内，那么使用 OutputDebugString 应该不会对您造成太大伤害。但是，请记住，一旦系统上有人开始收听此输出，就会发生减速。
回答by aJ.
I had read in an article that OutPutDebugString internally does few interesting things:
我在一篇文章中读到 OutPutDebugString 在内部做了一些有趣的事情：
- Creates\Opens mutex and wait infinitely till mutex is acquired.
- 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.
- 创建\打开互斥锁并无限等待直到获得互斥锁。
- 在应用程序和调试器之间传递数据是通过一个 4kbyte 的共享内存块完成的，有一个互斥锁和两个事件对象来保护对它的访问。
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.
即使未附加调试器（在发布模式下），使用 OutputDebugstring 以及使用各种内核对象也会产生大量成本。
Performance hit is very evident if you write a sample code and test.
如果您编写示例代码并进行测试，则性能下降是非常明显的。
回答by Bob Moore
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 impressionthat 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.
多年来，我在数十个服务器端发布模式应用程序中没有发现问题，所有这些应用程序都具有内置指标。你可以得到的印象，它是缓慢的，因为大多数你可以找到调试捕捉器的应用程序（DBWIN32等）是相当缓慢的，在投掷的数据在屏幕上，这给了滞后的印象。
Of course all of our applications have this output disabled by default, but it isuseful 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.
当然，我们所有的应用程序都将此输出默认是禁用的，但它是能在现场打开它很有用，因为你可以再从多个应用程序，在像DBWin32连载查看调试输出。对于涉及通信应用程序的错误，这可能是一种非常有用的调试技术。
回答by Stefan
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.
切勿在发布版本中保留 OutputDebugString() 调用。始终使用 #ifdef 语句删除它们，或者提供另一个开关来关闭它们。
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 DebugViewto catch the output of apps, but of course that's only good if not every app chatters along for no good reason.
有DebugView来捕捉应用程序的输出，但当然，如果不是每个应用程序都无缘无故地喋喋不休，那当然是好的。
回答by Stefan
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.
为什么不自己测量呢？编译以下代码，运行它并计时。然后删除对 OutputDebugString 的调用，重新编译并重新运行。应该花大约三分钟的时间。
#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;
}
回答by Stephen Kellett
I was curious about this topic so I did some research.
我对这个话题很好奇，所以我做了一些研究。
I've posted the results, the source code and project files so that you can repeat the tests for your setup. Covers running a release mode app without anything monitoring OutputDebugString and then with Visual Studio 6, Visual Studio 2005 and Visual Studio 2010 monitoring OutputDebugString to see what differences in performance there are for each version of Visual Studio.
我已经发布了结果、源代码和项目文件，以便您可以为您的设置重复测试。涵盖在没有任何监控 OutputDebugString 的情况下运行发布模式应用程序，然后使用 Visual Studio 6、Visual Studio 2005 和 Visual Studio 2010 监控 OutputDebugString 以查看每个 Visual Studio 版本的性能差异。
Interesting results, Visual Studio 2010 processes OutputDebugString information up to 7x slower than Visual Studio 6.
有趣的结果是，Visual Studio 2010 处理 OutputDebugString 信息的速度比 Visual Studio 6 慢 7 倍。
Full article here: Whats the cost of OutputDebugString?
