Jump to content
  • Advertisement

Archived

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

Xeee

Memory Allocation/Deallocation in Time-Critical Zones

This topic is 5477 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

I was wondering, how bad is it to allocate/deallocate (using new for instance) memory in the game loop (not when loading the level or something), if it is very bad, how to avoid it? thanks in advance. xee..

Share this post


Link to post
Share on other sites
Advertisement
It depends on the amount of elements you allocate or deallocate things. If your number of mallocs is small (let''s say under 100 per frame I suppose) then it''s probably not a problem. Try a benchmark on the malloc in your system.

Else the quickest memory allocator is called a pool. It''s nearly costless in speed. It''s very easy to code. It''s perfect for small structures that you need to allocate or delete quickly, for instance nodes in a dynamic tree, entities in your game. It''s a simple linked list of small memory blocks, elements of the size of your structure in a continuous chunk of memory (for instance n1=1024 elements. When there is not enough memory the pool grows by allocating (malloc) a new chunk of n2 blocks (ex:128 elements). so it adapts to the creast of your memory requirements for that particular structure.

To me any 3D or intensive real time code should include at least a basic pool allocator.

try a Google search with : pool memory allocation

This should give you more details.

Share this post


Link to post
Share on other sites
To be honest, all my little games do allocation and deallocation all over the place, and the bottleneck is always the graphics rendering. I think allocation is only going to be a problem if you do a hell of a lot of it and you''re really going for top performance where every cycle counts.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Share this post


Link to post
Share on other sites
quote:
Original post by Xeee
I was wondering, how bad is it to allocate/deallocate...


Nobody can tell you how bad it is for your code because every case is different. Someone might reply to your post saying that malloc slows everything down, but you could have the exact opposite experience. The rule of thumb is that memory allocation is slow, but if you need to know how slow it is, you are going to have to profile it yourself.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Well there are 3 main concerns when your doing news/deletes in a game which is pretty much an infinate loop.

#1. news/deletes are probably the slowest operations that you could possibly use.

#2. when newing/deleting memory in an infinate loop your bound to get what''s called memory fragmentation. When this happens it will take longer to locate a correct sized block of memory to allocate with new, and even though you may have a few megs of memory free there might not be enough memory in a continuious block to allocate for your uses.

#3. You must always be concerned about memory leaking.


The only way to really avoid the problems above is to create your own memory management system.

The two most likely to be used are covered in 2 seperate books,
There is a frame based memory management system covered in Game programming Gems1, and there is another type of memory management system covered in "C++ for game programmers" which works with pc/xbox. Both of these memory management systems are for games so there is an emphesis on keeping things clean, quick, and being able to detect memory leaks.

Share this post


Link to post
Share on other sites
I did a search on google, and i didn''t get any relevant source code or articles, so if any of you have some source code of simple pool memory allocation system, I''d b grateful, otherwise, please someone give me an accurate description of what the system should do, thanks very much.

xee..

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Basically, a pool allocator class should keep a memory pointer, current offset, and size members.

it needs two member functions for allocation and resetting. allocation returns a pointer to memory + current offset, and increases current offset by the # of bytes requested (potentially rounding up for alignment). reset() sets current offset to zero.

It''s simple and fast, and the two functions can be inlined.

Also, I think 100 mallocs a frame might be OK for small projects, but 100 mallocs * 60 FPS = 60,000 mallocs, leaving roughly 17 microseconds per alloc. Which is _shockingly_ fast even assuming you do nothing else per frame. If your app does lots of allocations for level data, instead of a single alloc for the entire data, you''re potentially creating quite a lot of data for malloc to run through after a few levels. I got burned in such a situation with way fewer than 100 mallocs a frame.

But, since one app''s heap won''t look like another''s, you mileage WILL vary.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!