6

我的 VS2012 编译器有一个奇怪的问题，似乎没有出现在 GCC 中。解除分配过程最终需要几分钟而不是几秒钟。有人对此有任何意见吗？步骤调试显示调用 RtlpCollectFreeBlocks() 时出现明显的挂起。我在调试和发布模式下都有这个问题。我正在运行 Windows 7 32 位，但我在 64 位 7 上遇到了同样的问题。 

#include "stdafx.h"
#include <iostream>
#include <stdint.h>
#include <cstdlib>

#define SIZE 500000

using namespace std;

typedef struct
{
    uint32_t* thing1;
}collection;

/*
 * VS2012 compiler used.
 * Scenarios: 
 *  1) Don't allocate thing1. Program runs poorly.
 *  2) Allocate thing1 but don't delete it. Program runs awesome.
 *  3) Allocate thing1 and delete it. Program runs poorly.
 * 
 * Debug or Release mode does not affect outcome. GCC's compiler is fine.
 */
int _tmain(int argc, _TCHAR* argv[])
{
    collection ** colArray = new collection*[SIZE];

    for(int i=0;i<SIZE;i++)
    {
        collection * mine = new collection;
        mine->thing1 = new uint32_t; // Allocating without freeing runs fine. Either A) don't allocate or B) allocate and delete to make it run slow.
        colArray[i] = mine;
    }

    cout<<"Done with assignment\n";

    for(int i=0;i<SIZE;i++)
    {
        delete(colArray[i]->thing1); // delete makes it run poorly.
        delete(colArray[i]);

        if(i > 0 && i%100000 == 0)
        {
            cout<<"100 thousand deleted\n";
        }
    }
    delete [] colArray;

    cout << "Done!\n";
    int x;
    cin>>x;
}
4

1 回答 1

8

您看到的性能冲击来自 Windows 调试堆功能，并且它在如何启用自身方面有点隐秘，即使在发布版本中也是如此。

我冒昧地构建了一个更简单程序的 64 位调试映像，并发现了这一点：

  • msvcr110d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x0000000001a8b540)
  • msvcr110d.dll!_free_dbg_nolock(void * pUserData=0x0000000001a8b540, int nBlockUse=1)
  • msvcr110d.dll!_free_dbg(void * pUserData=0x0000000001a8b540, int nBlockUse=1)
  • msvcr110d.dll! 运算符删除（无效 * pUserData=0x0000000001a8b540）

我特别感兴趣的是msvcr110d.dll!_CrtIsValidHeapPointer它原来是这样的身体：

if (!pUserData)
    return FALSE;

// Note: all this does is checks for null    
if (!_CrtIsValidPointer(pHdr(pUserData), sizeof(_CrtMemBlockHeader), FALSE))
    return FALSE;

// but this is e-x-p-e-n-s-i-v-e
return HeapValidate( _crtheap, 0, pHdr(pUserData) );

那个HeapValidate()呼唤是残酷的。

好的，也许我希望在调试版本中做到这一点。但肯定不会释放。事实证明，情况会变得更好，但请查看调用堆栈：

  • ntdll.dll!RtlDebugFreeHeap()
  • ntdll.dll!string "启用堆调试选项\n"()
  • ntdll.dll!RtlFreeHeap()
  • kernel32.dll!HeapFree()
  • msvcr110.dll!free(void * pBlock)

这很有趣，因为当我首先运行它时，然后使用 IDE（或 WinDbg）附加到正在运行的进程，而不允许它控制执行启动环境，这个调用堆栈在ntdll.dll!RtlFreeHeap(). 换句话说，RtlDebugFreeHeap不会调用在 IDE 之外运行。但为什么？？

我心想，不知何故，调试器正在翻转开关以启用堆调试。在做了一些挖掘之后，我发现“开关”就是调试器本身。如果正在运行的进程是由调试器生成的，Windows 将使用特殊的调试堆函数 (RtlDebugAllocHeap和)。这个来自 MSDN on WinDbg 的手册页避开了这一点，以及其他关于在 Windows 下调试的有趣花絮：RtlDebugFreeHeap

来自使用 WinDbg 调试用户模式进程

调试器创建的进程（也称为衍生进程）的行为与调试器未创建的进程略有不同。

调试器创建的进程不使用标准堆 API，而是使用特殊的调试堆。您可以使用 _NO_DEBUG_HEAP 环境变量或 -hd 命令行选项强制生成的进程使用标准堆而不是调试堆。

现在我们正在取得进展。为了测试这一点，我只是放弃了sleep()一个适当的时间来附加调试器，而不是用它生成进程，然后让它以快乐的方式运行。果然，如前所述，它全速前进。

根据那篇文章的内容，我冒昧地更新了我的发布模式构建，以_NO_DEBUG_HEAP=1在我的项目文件的执行环境设置中定义。我显然仍然对调试构建中的粒度堆活动感兴趣，所以这些配置保持原样。这样做之后，我在 VS2012（和 VS2010）下运行的发布版本的整体速度大大加快了，我也邀请您尝试一下。

于 2013-09-11T23:49:02.553 回答