我最近注意到在gdb中运行一个程序使得它慢很多，我想知道为什么。
这是一个例子：
这是一个纯粹的C ++ 03项目，用mingw32（gcc 4.8.1,32位）编译。
它是静态链接到libstdc ++和libgcc，没有其他的lib被使用。
这是一个cpu和内存密集型非并行处理（一个网格编辑操作，大量的消息，删除和查询涉及的数据结构）。
问题不是启动时间，整个过程是痛苦的缓慢。
debugging版本（-O0 -g2）在gdb之外运行8秒，但在gdb之内运行140秒。
从命令行testing，只需启动gdb，然后input“run”（没有定义断点）。
我还testing了一个发布版本（已优化，没有debugging信息），而且在gdb内部仍然慢得多（3秒vs 140秒;是的，它与gdb中的未优化版本相同）。
用mingw32项目testinggdb 7.5和7.6，用我编译的gdb 7.8（全部不用python支持）。
我通常在GNU / Linux上开发，在那里我不能注意到使用gdb或者运行gdb的速度差异。
我想知道gdb做的是什么让它运行得如此之慢。 我对debugging器的工作原理有了一些基本的了解，但是我无法弄清楚它在这里做了些什么，而这次使用googlesearch并没有帮上忙。
32位Linux时钟（）溢出
奇怪的键值由ncurses打印
获得相邻设备的接收信号强度
closures窗体没有退出应用程序
确定两个文件path是否指向Linux / C下的同一个文件？
我怎么能告诉我用什么窗口主题？
如何编译OpenSSL for x64？
如何使用多个版本的GCC
发送SKB从内核空间传输
我终于找到了问题，感谢伟大的狼人要求我测试其他调试器。 Ollydbg需要与gdb相同的时间，所以它不是一个gdb问题，它是一个Windows问题。 这个技巧改变了我的搜索条件，然后我发现这篇文章*解释了这个问题，并给出了一个非常简单的解决方案：定义一个环境变量_NO_DEBUG_HEAP为1.这将禁用一个特殊的堆系统windows提供和c ++程序使用。
*这是链接： http : //preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger/
我曾经有过gdb的速度非常慢的问题，我记得禁用nls（本地语言支持，即所有消息的翻译）可以弥补这一点。
配置时间选项是--disable-nls 。 我可能只是误以为真正的原因是什么，但无论如何也值得一试。
我当时的错误报告在这里 ，虽然结论会是我错了。 如果你能提供进一步的见解，那就太棒了！
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
