为什么运行附加到调试器这么慢？ [英] Why is running attached to the debugger so slow?

问题描述

与未附加的调试器相比，这会导致调试构建如此慢地连接到调试器上怎么办？他们都是同一个exe运行。

What is going on that causes a debug build to be so much slower attached to the debugger compared to unattached? They are both the same exe running.

编辑：大多数的答案集中在断点。我仍然像泥没有断点，OutputDebugString，或任何在观察窗口运行。

Most of the answers concentrate on breakpoints. I'm still running like mud without breakpoints, OutputDebugString, or anything in the watch window. What about debug CRT, Runtime stack checks, and the debug heap?

推荐答案

如果不是 OutputDebugString 或者堆和堆的断点减慢了一切，请尝试这些：

If it isn't OutputDebugString or piles and piles of breakpoints slowing everything down, try these:

• Windows调试堆 - 你的进程获得调试堆，如果它在调试器下运行，没有问题。要在Visual Studio调试器下运行时禁用此功能，请访问项目属性的调试页面，并将 _NO_DEBUG_HEAP = 1 添加到环境中。

（Windows调试堆是与CRT调试堆分离的一个单独的东西，如果它在调试器下运行，你的发布版本也会得到Windows调试堆。）

(The Windows debug heap is a separate thing from the CRT debug heap. Your release build will get the Windows debug heap too, if it runs under a debugger.)

程序加载了许多具有符号的DLL。加载DLL时，Visual Studio会尝试查找它的符号。如果有符号可用，这可能需要时间。

The program loads lots of DLLs that have symbols. When a DLL is loaded, Visual Studio tries to find symbols for it. If there are symbols available, this can take time. There's not much you can do about this except to rearrange your program so that it loads DLLs less often.

检查任何对的调用， IsDebuggerPresent - 这可以引入在调试器和其外部运行之间的任意差异。

Check for any calls to IsDebuggerPresent - this can introduce arbitrary differences between running in the debugger and outside it.

（作为一个最终的一次性建议 - 我也怀疑异常（无论是C ++还是结构化的）在进程被调试时可能会更多的涉及到所以如果你的程序抛出很多，也许这可能会有点慢正在调试。）

(As a final throwaway suggestion - I would also be suspicious that exceptions (whether C++ or structured) might be a bit more involved when the process is being debugged. So if your programs throws a lot, maybe that could be a bit slower when it's being debugged.)

这篇关于为什么运行附加到调试器这么慢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！