Memory Footprints
Author
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
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
Next we allocate 3 more units of memory
Freeing the first allocation
And allocating 2 more
Now look what happens when your memory buffer is expanded in size, (V is the number of verticies),
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]
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]
Just occurred to me while going to sleep last night how simple it is to work out the heap size after allocating n units.
Pretty obvious really, I mustn''t have been thinking before
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
