#### Archived

This topic is now archived and is closed to further replies.

# Memory Footprints

This topic is 5538 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey all, I''m writting a quad-tree and I have to make lots of triangle splits. Each time I split a triangle, I have to add one (often two) new verticies, normals, and texture coordinates to a set of arrays which I use for rendering (in OpenGL).. Now, this is all fine and dandy. When I add new verticies to say, the vertex array, I just do varray = ExpandBuffer(varray, sizeof(Vertex)); and then varray is re-malloced to fit in the new vertex... ExpandBuffer looks a little something like this : void* ExpandBuffer(void* in, int size) { void* ret; ret = malloc( _msize(in) + size); memcpy(in, ret, _msize(ret)); free(in); return(ret); } So you see, whenever I expand a buffer, I actually just create a new slightly large one and copy the contents of the old one..... So I run the quad-tree and generate what I think is a reasonable amound of triangles to be working with for a given level, and the thing uses up 50 Megs of RAM!!! I think it''s because that "free()" call, doens''t do a damn thing, and the memory just sits there and doesn''t get returned to the system..... Can anyone help me out?!?! -Mr.Oreo

##### Share on other sites
What measure have you used to achieve that 50meg value?

##### Share on other sites
Memory fragmentation!

While different memory allocation algorithms work differently, they will all suffer from a similar problem. For purposes of illustration, suppose that memory is allocated by returning the first available block on the heap of the required size.

For example:

Suppose we have an empty heap
..........

Then we allocate 4 units of memory
AAAA......

Next we allocate 3 more units of memory
AAAABBB...

Freeing the first allocation
....BBB...

And allocating 2 more
CC..BBB...

Now look what happens when your memory buffer is expanded in size, (V is the number of verticies),
    HeapV   Size  Heap1   1     x2   3     .xx3   6     ...xxx4   10    ......xxxx5   10    xxxxx.....6   11    .....xxxxxx7   18    ...........xxxxxxx8   18    xxxxxxxx..........9   18    ........xxxxxxxxx.10  28    ..................xxxxxxxxxx11  28    xxxxxxxxxxx.................12  28    ...........xxxxxxxxxxxx.....13  36    .......................xxxxxxxxxxxxx14  36    xxxxxxxxxxxxxx......................15  36    ..............xxxxxxxxxxxxxxx.......16  45    .............................xxxxxxxxxxxxxxxx

As you can see, alot more memory is used than is actually required.

Using realloc instead of malloc/memcpy/free would get rid of the problem I would guess (depends on how the operating system makes extra memory available to the application). Plus it also simplifies the code

Out of interest, can anyone figure out what size the heap will be after we allocate n units?

[edited by - Luke Hutchinson on April 21, 2003 11:39:56 AM]

##### Share on other sites
Just occurred to me while going to sleep last night how simple it is to work out the heap size after allocating n units.
size_t HeapSize( size_t n ){    static const size_t lessThan7[7] = { 0, 1, 3, 5, 10, 10, 11 };    if( n < 7 )        return lessThan7[n];    return 3 * ( n - (n-7)%3 ) - 3;}

Pretty obvious really, I mustn''t have been thinking before

• 17
• 11
• 12
• 9
• 49
• ### Forum Statistics

• Total Topics
631395
• Total Posts
2999758
×