Visual C++:在发布模式下启动/不调试之间的区别

发布于 2024-09-12 03:08:11 字数 404 浏览 2 评论 0原文

开始调试 (F5)启动但不调试 (CTRL-F5) 之间有什么区别代码何时以发布模式编译?

我发现对于某些 C++ 代码, CTRL-F5F5 快 10 倍。如果我没记错的话,调试器附加到 F5 的执行进程,而不是 CTRL-F5 的执行进程。由于这是Release模式,编译后的代码没有任何调试信息。因此,如果我没有任何断点,两者的执行时间应该相同,不是吗?!

(假设“发布”和“调试”模式是创建新的 Visual C++ 项目时获得的典型配置。)

What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?

I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!

(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

猫烠⑼条掵仅有一顆心 2024-09-19 03:08:12

问题是,如果 Windows 检测到您的程序正在调试器下运行,则会放入一个特殊的调试堆中。这似乎发生在操作系统级别,并且与编译的任何调试/发布模式设置无关。

您可以通过设置环境变量来解决此“功能”: _NO_DEBUG_HEAP=1

这个同样的问题已经让我发疯了一段时间;今天我发现了以下内容,这篇文章就是从那里衍生出来的:
http://blogs.msdn .com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx

The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.

You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1

This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx

残疾 2024-09-19 03:08:12

“启动而不调试”只是告诉 Windows 像正常运行一样启动应用程序。

“从调试开始”启动 VS 调试器并让它在调试器中运行应用程序。

这实际上与调试/发布构建设置没有太大关系。

当您构建应用程序的默认“调试”配置时,您将与发布版本有以下主要区别:

  • 发出的代码不会被优化,因此更容易调试,因为它更接近您的源代码
  • 编译器和;链接器将输出一个包含大量额外信息的 .PDB 文件以帮助调试器 - 此信息的存在或不存在对代码的性能没有影响,只是调试的容易程度。
  • 像 ASSERT 和 VERIFY 这样的条件宏在发布版本中将是无操作的,但在调试版本中是活动的。

这些项目中的每一项都是独立且可选的!您可以打开或关闭其中任何一项或全部,并且仍然在调试器下运行代码,您只是不会发现生活如此轻松。

当您运行“调试”时,由于以下几个原因,事情会表现不同:

  • VS 调试器在启动时效率非常低,部分原因是 VS 中的所有内容都很慢 - 在 VS2010 之前的版本上,屏幕的每个像素将像 IDE 一样重新绘制大约 30 次摇摇晃晃地进入调试模式,并伴有大量闪烁。
  • 根据配置方式,调试器可能会在启动时花费大量时间尝试为进程中的大量操作系统组件加载符号(即 PDB 文件) - 它可能会尝试通过网络获取这些文件,在某些情况下,这可能需要一段时间。
  • 应用程序通常执行的许多活动(加载 DLL、启动线程、处理异常)都会导致调试器收到警报。这既可以减慢它们的速度,又可以使它们倾向于按顺序运行。

"Start without debugging" just tells Windows to launch the app as it would normally run.

"Start with debugging" starts the VS debugger and has it run the app within the debugger.

This really doesn't have much to do with the debug/release build settings.

When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:

  • The emitted code won't be optimised, so is easier to debug because it more closely matches your source
  • The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
  • Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.

Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.

When you run 'with debugging' things perform differently for several reasons:

  • The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
  • Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
  • A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
彩虹直至黑白 2024-09-19 03:08:12

IsDebuggerPresent()OutputDebugString()< /a> 根据是否附加调试器而表现不同。

IsDebuggerPresent() 只是返回另一个值,因此您的程序可以对此值做出反应并故意表现出不同的行为。当没有附加调试器时,OutputDebugString() 返回速度要快得多,因此,如果多次调用它,您会发现程序在没有调试器的情况下运行得更快。

IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.

IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.

懒的傷心 2024-09-19 03:08:12

当“带调试”运行时,即使对于发布模式,也会使用调试堆。这会导致使用大量 malloc/free 或 new/delete 的代码严重减慢,这可能在 C++ 代码中发生,而您却没有注意到,因为库/类往往向您隐藏这些内存管理内容。

When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文