Destructor for CArray takes about 30 seconds to run - c++

Question

I'm curious if someone could explain to me why when I call a destructor on the following array:
CArray<READ_ENTRY> arr;
It takes about 30 seconds to finish?
The arr array at the time has about 240,000 entries, which I thought wasn't that many. Also to compare memory usage, I took the working set from the Task Manager for my process before that array is filled in and after, and the working set grew by about 322 MB.
Also if there's something that I can do to optimize/speed it up?
EDIT:
The data that is being stored in this array is distributed as such:
CString members contain relatively short strings that are between 10 to 300 wchars long.
My MEM_ARRAY byte arrays also contain relatively small amounts of data:
procPrivs is about 20-100 bytes on average.
userSID is even smaller, it's the size of the user's SID (no more than 50 bytes.)
The rest are just 4 or 8 byte members.
EDIT2: In Release build it takes exactly the same amount of time to run.
The following structures are defined as such:
struct READ_ENTRY{
DWORD flags;
FILETIME ftLogTimeUTC;
short wTimeDiffMin;
int nOSErrorCode;
int nSpecCode;
DWORD dwMessageID;
DWORD dwMessageCtr;
DWORD dwMessageAllowBackSecs;
BYTE wProductType;
DWORD dwOSType;
DWORD dwMajorVersion;
DWORD dwMinorVersion;
DWORD dwBuildNumber;
WORD wServicePackMajor;
WORD wServicePackMinor;
WORD wSuiteMask;
WORD wProcessorArchitecture;
ULONGLONG dwActiveProcessorMask;
DWORD dwProcID;
DWORD dwThreadID;
LCID lcidThread;
MEM_ARRAY procPrivs;
CString strUserName;
MEM_ARRAY userSID;
CString strModName;
CString strMsgTitle;
CString strMsgDesc;
READ_ENTRY()
{
flags = DBXF_NONE;
ftLogTimeUTC.dwLowDateTime = 0;
ftLogTimeUTC.dwHighDateTime = 0;
wTimeDiffMin = 0;
nOSErrorCode = 0;
nSpecCode = 0;
dwMessageID = 0;
dwMessageCtr = 0;
dwMessageAllowBackSecs = 0;
wProductType = 0;
dwOSType = 0;
dwMajorVersion = 0;
dwMinorVersion = 0;
dwBuildNumber = 0;
wServicePackMajor = 0;
wServicePackMinor = 0;
wSuiteMask = 0;
wProcessorArchitecture = 0;
dwActiveProcessorMask = 0;
dwProcID = 0;
dwThreadID = 0;
lcidThread = NULL;
}
};
and:
struct MEM_ARRAY{
BYTE* pMem;
int ncbSzMem;
MEM_ARRAY() :
pMem(NULL)
, ncbSzMem(0)
{
}
~MEM_ARRAY()
{
freeMem();
}
MEM_ARRAY(BYTE* pSrcSID, int ncbSz) :
pMem(NULL)
, ncbSzMem(0)
{
copyMem(pSrcSID, ncbSz);
}
MEM_ARRAY(const MEM_ARRAY& s) :
pMem(NULL)
, ncbSzMem(0)
{
copyMem(s.pMem, s.ncbSzMem);
}
MEM_ARRAY& operator = (const MEM_ARRAY& s)
{
copyMem(s.pMem, s.ncbSzMem);
return *this;
}
void freeMem()
{
if(pMem)
{
delete[] pMem;
pMem = NULL;
}
ncbSzMem = 0;
}
void copyMem(BYTE* pSrcSID, int ncbSz)
{
if(pSrcSID != pMem)
{
freeMem();
pMem = new (std::nothrow) BYTE[ncbSz];
ASSERT(pMem);
if(pMem)
{
memcpy(pMem, pSrcSID, ncbSz);
ncbSzMem = ncbSz;
}
}
else
ASSERT(ncbSz == ncbSzMem);
}
};
EDIT3: Here's a sample of how to fill in the array:
#define SIZEOF(f) (sizeof(f) / sizeof(f[0]))
{
CArray<READ_ENTRY> arr;
BYTE dummy[256];
srand((UINT)time(NULL));
for(int i = 0; i < sizeof(dummy); i++)
dummy[i] = (BYTE)rand();
READ_ENTRY re;
arr.SetSize(240000); //Optimize it, since we know the final size
for(int t = 0; t < 240000; t++)
{
static LPCTSTR words[] = {
L"success", L"added", L"new", L"entry",
L"didn't", L"counter", L"as", L"ran",
L"out", L"this", L"first", L"because",
L"the", L"just", L"error", L"if",
L"or", L"manually", L"simple", L"program",
L"how", L"what", L"title", L"great",
};
CString strTitle;
int nCntW = GetRandomNumber(0, 12);
for(int i = 0; i < nCntW; i++)
{
if(!strTitle.IsEmpty())
strTitle += L" ";
strTitle += words[GetRandomNumber(0, SIZEOF(words))];
}
CString strDesc;
int nCntWDesc = GetRandomNumber(0, 100);
for(int i = 0; i < nCntWDesc; i++)
{
if(!strDesc.IsEmpty())
strDesc += L" ";
strDesc += words[GetRandomNumber(0, SIZEOF(words))];
}
re.strMsgTitle = strTitle; //Use some randomness for these members
re.strMsgDesc = strDesc;
re.strModName = L"Test Module v.1.0.0.0";
re.strUserName = L"mycomputername\\my user name";
re.procPrivs.copyMem(dummy, GetRandomNumber(10, 100));
re.userSID.copyMem(dummy, GetRandomNumber(10, 50));
arr.SetAtGrow(t, re);
}
//Destructor will be called here
}
ULONG GetRandomNumber(ULONG nNumMin, ULONG nNumMax)
{
ULONG nMin, nMax;
if(nNumMin <= nNumMax)
{
nMin = nNumMin;
nMax = nNumMax;
}
else
{
nMin = nNumMax;
nMax = nNumMin;
}
ULONG nRnd = ((ULONG)(rand() & 0x7fff) << 17) |
((ULONG)(rand() & 0x7fff) << 2) |
((ULONG)(rand() & 0x3));
return nMax > nMin ? (nRnd % (nMax - nMin)) + nMin : nMin;
}

Answer 1

Is the problem happening in release build too? (I cant comment it seems noobs dont get enough reputation to comment). what platform?
If the slow down is there in release build as well and you are seeing CPU spikes on delete then you might want to fix your data structures, at the risk of stating the obvious you'r heap is being stressed out. Freeing large amount of memory is a highly CPU intensive task.
You can ... Try clubbing the memory blocks into a larger block. Use fixed length strings, it will cause external fragmentation but you can decide where to draw the line.
One approach is to have the Carray per CPU and a separate heap for each one of them. This will make allocation and deallocation more concurrent.