[RESOLVED] Can anyone explain why a processes memory grows like this...?

[AnotherMuggle]

I am confused why the size of a process grows larger in size for lots of small memory allocations.

For example, say I have this struct, which is 16 bytes (for a 32 bit build):

struct Person
{
    int iID;
    int iAge;
    char * pForeName;
    char * pSurName;
};

If I allocate memory like this:

LPBYTE lpB = new BYTE[sizeof(Person) * 1000000];

then my process grows to 16,48KB in size, which is what I expected. However if I allocate memory like this:

    Person * lpPerson;
    for(int i = 0; i < 1000000; ++i)
        lpPerson = new Person;

then the process grows to 78,656KB, which I don't understand.

Additionally, I was surprised to find a vector acts more similarly to the first example. This code:

    Person temp = { 0 };
    std::vector<Person> people;
    for(int i = 0; i < 1000000; ++i)
        people.push_back(temp);

only increases the process memory to 16,892.

Is anyone able to explain why the lots of small allocations grows the process memory to such a huge size and/or why a vector doesn't suffer with the same issue?

Cheers,
AnotherMuggle

[laserlight]

Maybe because there is book keeping associated with each allocation, hence more allocations mean more book keeping. The vector probably does not have that issue because it uses memory akin to your first example (except that it periodically expands the capacity when the current capacity has been reached, such that the push_back still operates in amortised constant time), though it avoids creating the objects that are not yet part of the vector's size.

[Paul McKenzie]

I am confused why the size of a process grows larger in size for lots of small memory allocations.

Each one of those allocations requires management, and the heap manager needs to expand to keep track of them.

Not only that, the runtime may allocate more memory per request for things such as debug checking, guard bytes, etc.

Regards,

Paul McKenzie

[AnotherMuggle]

Maybe because there is book keeping associated with each allocation, hence more allocations mean more book keeping. The vector probably does not have that issue because it uses memory akin to your first example (except that it periodically expands the capacity when the current capacity has been reached, such that the push_back still operates in amortised constant time), though it avoids creating the objects that are not yet part of the vector's size.

Each one of those allocations requires management, and the heap manager needs to expand to keep track of them.

Not only that, the runtime may allocate more memory per request for things such as debug checking, guard bytes, etc.

Regards,

Paul McKenzie

Two Elite Members, two good answers, what more could I ask for. Thanks both!

[2kaud]

Just because you ask for n bytes of allocated memory, this does not mean that Windows actually allocates n bytes. It only guarantees to either allocate at least n bytes or report failure. On my system if you look at the memory allocated, Windows is actually allocating the memory in chuncks of either 24 bytes or 32 bytes rather than the 16 bytes requested.

[waolaxio12]

phim sex vip free,down phim sex 3gp|tai phim sex