当我连接调试器/IDE 时,为什么我的 STL 代码运行如此缓慢?

发布于 2024-07-25 22:41:21 字数 1323 浏览 2 评论 0原文

我正在 Windows Vista Business x64、四核计算机、8GB RAM 上使用 Visual Studio 2008 SP1 运行以下代码。

如果我构建一个发布版本,并从命令行运行它,它会报告 31 毫秒。 如果我随后使用 F5 从 IDE 启动它,它会报告 23353ms。

以下是时间:(所有 Win32 版本)

  • DEBUG,命令行:421ms
  • DEBUG,来自 IDE:24,570ms
  • RELEASE,命令行:31ms
  • RELEASE,来自 IDE:23,353ms

代码:

#include <windows.h>
#include <iostream>

#include <set>
#include <algorithm>
using namespace std;

int runIntersectionTestAlgo()
{   

    set<int> set1;
    set<int> set2;
    set<int> intersection;


    // Create 100,000 values for set1
    for ( int i = 0; i < 100000; i++ )
    {
        int value = 1000000000 + i;
        set1.insert(value);
    }

    // Create 1,000 values for set2
    for ( int i = 0; i < 1000; i++ )
    {
        int random = rand() % 200000 + 1;
        random *= 10;

        int value = 1000000000 + random;
        set2.insert(value);
    }

    set_intersection(set1.begin(),set1.end(), set2.begin(), set2.end(), inserter(intersection, intersection.end()));

    return intersection.size(); 
}

int main(){
    DWORD start = GetTickCount();

    runIntersectionTestAlgo();

    DWORD span = GetTickCount() - start;

    std::cout << span << " milliseconds\n";
}

I'm running the following code, using Visual Studio 2008 SP1, on Windows Vista Business x64, quad core machine, 8gb ram.

If I build a release build, and run it from the command line, it reports 31ms. If I then start it from the IDE, using F5, it reports 23353ms.

Here are the times: (all Win32 builds)

  • DEBUG, command line: 421ms
  • DEBUG, from the IDE: 24,570ms
  • RELEASE, command line: 31ms
  • RELEASE, from IDE: 23,353ms

code:

#include <windows.h>
#include <iostream>

#include <set>
#include <algorithm>
using namespace std;

int runIntersectionTestAlgo()
{   

    set<int> set1;
    set<int> set2;
    set<int> intersection;


    // Create 100,000 values for set1
    for ( int i = 0; i < 100000; i++ )
    {
        int value = 1000000000 + i;
        set1.insert(value);
    }

    // Create 1,000 values for set2
    for ( int i = 0; i < 1000; i++ )
    {
        int random = rand() % 200000 + 1;
        random *= 10;

        int value = 1000000000 + random;
        set2.insert(value);
    }

    set_intersection(set1.begin(),set1.end(), set2.begin(), set2.end(), inserter(intersection, intersection.end()));

    return intersection.size(); 
}

int main(){
    DWORD start = GetTickCount();

    runIntersectionTestAlgo();

    DWORD span = GetTickCount() - start;

    std::cout << span << " milliseconds\n";
}

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

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

发布评论

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

评论(3

流年已逝 2024-08-01 22:41:21

默认情况下,在 Microsoft 调试器(windbg、kd、cdb、Visual Studio 调试器)下运行会强制 Windows 使用调试堆而不是默认堆。 在 Windows 2000 及更高版本上,默认堆是低碎片堆,与调试堆相比,这非常好。 您可以使用 HeapQueryInformation。

要解决您的特定问题,您可以使用此知识库文章中推荐的众多选项之一:为什么碎片堆较低(LFH) 机制可能在某些运行 Windows Server 2003、Windows XP 或 Windows 2000 的计算机上被禁用

对于 Visual Studio,我更喜欢将 _NO_DEBUG_HEAP=1 添加到 项目属性->配置属性->调试->环境。 这总是对我有用。

Running under a Microsoft debugger (windbg, kd, cdb, Visual Studio Debugger) by default forces Windows to use the debug heap instead of the default heap. On Windows 2000 and above, the default heap is the Low Fragmentation Heap, which is insanely good compared to the debug heap. You can query the kind of heap you are using with HeapQueryInformation.

To solve your particular problem, you can use one of the many options recommended in this KB article: Why the low fragmentation heap (LFH) mechanism may be disabled on some computers that are running Windows Server 2003, Windows XP, or Windows 2000

For Visual Studio, I prefer adding _NO_DEBUG_HEAP=1 to Project Properties->Configuration Properties->Debugging->Environment. That always does the trick for me.

甜尕妞 2024-08-01 22:41:21

在 VS IDE 中按暂停键显示额外的时间似乎花费在 malloc/free 上。 这让我相信,如果附加了调试器,MS 的 malloc 和 free 实现中的调试支持会有额外的逻辑。 这可以解释控制台和调试器的时间差异。

编辑:通过使用 CTRL+F5 v. F5 运行确认(在我的机器上为 1047ms v. 9088ms)

Pressing pause while in the VS IDE shows that the additional time appears to be spent in malloc/free. This would lead me to believe the debugging support in MS's malloc and free implementation have additional logic if the debugger is attached. This would explain the discrepancy in times from the console and from the debugger.

EDIT: Confirmed by running with CTRL+F5 v. F5 (1047ms v. 9088ms on my machine)

剑心龙吟 2024-08-01 22:41:21

所以听起来这可能就是附加调试器时发生的情况。 然而,我无法理解性能从 30 毫秒变为 23,000 毫秒,尤其是当我的代码的其余部分似乎运行得同样快,无论是否连接调试器。

So it sounds like this may just be what happens when one attaches the debugger. However, I just can't my head around the performance changing from 30ms to 23,000ms because of that, especially when the rest of my code seems to run just as fast whether or not the debugger is attached.

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