Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ memory
Hi!
 
I and some good friends of mine decided to try making a smaller game in C++ just for fun, with help of DirectX and some other libraries original written in C++. I would say all of us have experience from earlier development projects but however almost only from managed languages. I have been programming in C++ before but never any bigger projects or solutions.
 
When we did a bit of research we found that it seems like a lot of people worries about memory fragmentation on the heap when creating small short lived objects frequently or when the memory usage grows. We got a bit concerned that we may have to take this under consideration when designing the game engine, instead of just creating objects the C# or Java way with "new". (I'm aware of that you must free the memory unlike in the managed languages mentioned)
 
Is this something you should worry about and if so what are our options? I have read a bit about memory pools, but will we need one and is there any known already working we could use if so? We are very thankful for all feedback we get on this.
 
Best Regards
WaZoX
Posted 17-Dec-12 6:49am
WaZoX856
Edited 17-Dec-12 9:04am
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

I and some good friends of mine decided to try making a smaller game in C++ just for fun Great Big Grin | :-D
 
a lot of people worries about memory fragmentation
Many spend time worrying on things that eventually turn out not to be a problem ...
 
Is this something you should worry about
Probably not, but creating pools of same/similar sized objects can enhance the performance of your program - that's probably a better reason for using memory pools than fragmentation.
 
C# or Java way with "new". Just remember to delete those objects, or take a look at std::make_shared<> & std::shared_ptr<>
 
Regards
Espen Harlinn
  Permalink  
Comments
CPallini at 17-Dec-12 12:26pm
   
5.
Espen Harlinn at 17-Dec-12 12:28pm
   
Thank you, Carlo :-D
WaZoX at 17-Dec-12 13:51pm
   
Thank you very much for your input, sounds great that it doesn't seems to be such a big problem with fragmentation. Means more time for the game! Do you believe memory fragmentation would be a problem for bigger titles like AAA games? I'm aware of the delete keyword but thank you anyway :)
Espen Harlinn at 17-Dec-12 15:29pm
   
I expect they do, but then they have the manpower and budget to do so.
 
I think you'll find that they are way more concerned over how they manage memory on the graphics card and scheduling of the "events" that drives the game - think orchestration ...
Nelek at 17-Dec-12 18:17pm
   
Nice points. +5
Espen Harlinn at 17-Dec-12 19:34pm
   
Thank you, Nelek :-D
Sergey Alexandrovich Kryukov at 29-Dec-12 21:01pm
   
Nice, a 5.
—SA
Espen Harlinn at 30-Dec-12 5:22am
   
Thank you, Sergey :-D
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

A nice "epiphany" about advanced memory management Smile | :) :
16 used from $0.01[^]
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

In practice memory fragmentation could be a problem if you have a lot of objects of varying sizes.
 
If almost all your objects are relatively small, fragmentation should not be a problem.
 
On the other hand, if you uses a lot of large std::vector without reserveing memory, you will be prone to memory fragmentation because each time a reallocation occurs, the previously used memory would not be usable for another very large object.
 
If small and large objects allocations are a lot intermixed, the the problem can be worst.
 
It also depends a lot on how much memory you use. Given that nowaday machine have gigabytes of RAM, it is less aq problem that it used to be.
 
Also, you have to be sure that your application does not have memory leak as otherwise available memory will diminish as time goes.
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



Advertise | Privacy | Mobile
Web02 | 2.8.1411023.1 | Last Updated 18 Dec 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100