Jump to content
  • Advertisement

Archived

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

MrOreo

Memory Footprints

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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),

Heap
V Size Heap
1 1 x
2 3 .xx
3 6 ...xxx
4 10 ......xxxx
5 10 xxxxx.....
6 11 .....xxxxxx
7 18 ...........xxxxxxx
8 18 xxxxxxxx..........
9 18 ........xxxxxxxxx.
10 28 ..................xxxxxxxxxx
11 28 xxxxxxxxxxx.................
12 28 ...........xxxxxxxxxxxx.....
13 36 .......................xxxxxxxxxxxxx
14 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 this post


Link to post
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!