Sign in to follow this  
SymLinked

[C++] Are memory pools still important?

Recommended Posts

SymLinked    1233
I read a lot a few years ago, and some article stated that keeping a pool of often allocated/deallocated objects and picking free spots from that pool was more efficient than manually allocating via new or similiar. Now, looking at the present, do I still need to employ this or will the O/S memory manager do this for me when allocating from the heap?

Share this post


Link to post
Share on other sites
Andrew Kabakwu    941
Pools are still relevant. Its a matter of not doing SLOW work while the game/app is running.

Allocting a single oject each time is a waste compare to allocating a pool and growing it by a fixed size each time the pool runs out of free entries.

There are many ways of doing this, from custom methods to using STL classes (if using C++)

Share this post


Link to post
Share on other sites
SymLinked    1233
I just noticed Boost too has a common memory pool (Simple Segregated Storage) and it might just finally be my excuse to download the library.

Thanks again.

Share this post


Link to post
Share on other sites
Sneftel    1788
Pools are most certainly still relevant. One thing about pool allocation, though, is that it is one of the easiest optimizations to do "later". As long as you're using proper OOP techniques, moving from standard to pool allocation for a particular class has a trivial impact on user code. So yes, definitely still relevant, but often worth waiting to profile first.

Share this post


Link to post
Share on other sites
SymLinked    1233
Quote:
Original post by Sneftel
Pools are most certainly still relevant. One thing about pool allocation, though, is that it is one of the easiest optimizations to do "later". As long as you're using proper OOP techniques, moving from standard to pool allocation for a particular class has a trivial impact on user code. So yes, definitely still relevant, but often worth waiting to profile first.


Sorry for possibly asking the obvious, but what would the negative sides be of not waiting? Less readable code?

Share this post


Link to post
Share on other sites
Sneftel    1788
Pool allocation can make things more difficult to debug, as there's less sanity checking and more memory reuse. Also, it takes more time to do something than to not do it. If there's zero cost to waiting, and less than a hundred percent chance that you'll need it, you may as well wait. See YAGNI.

Share this post


Link to post
Share on other sites
Drigovas    509
A little tidbit on the increased simplicity of debugging non-pooling structures vs pooling structures: An access to a freed/deleted piece of memory is an access violation, an access to a piece of memory that is still owned but returned to a pool is not an access violation. It sounds silly, but a program error that fails catastrophically is much better than a code segment that MIGHT contain an error. For this exact reason, it is still a good idea, even for structures that use memory pools, to do all your debug work with a memory pool that actually allocates and releases memory behind the scenes, and uses proper memory pooling only in a release build.

Share this post


Link to post
Share on other sites
Evil Steve    2017
Memory pools are also extremely useful on platforms like DS where there's limited memory available and fragmentation is a major concern.

Share this post


Link to post
Share on other sites
RandomPixel    128
What about a "temporary variable pool"? For example a big struct with various of common variables. Then whenever you are going to use a temporary variable such as a for-counter or other things that only exist within the method, you can use a variable in this pool. The rule is that you will only use the pool within a method and not between another method (because that other method could be using the same variable in the pool). Maybe it won't improve the performance that much?

Share this post


Link to post
Share on other sites
Evil Steve    2017
Quote:
Original post by RandomPixel
What about a "temporary variable pool"? For example a big struct with various of common variables. Then whenever you are going to use a temporary variable such as a for-counter or other things that only exist within the method, you can use a variable in this pool. The rule is that you will only use the pool within a method and not between two methods (because that other method could be using the same variable in the pool). Maybe it won't improve the performance that much?
Local variables are effectively free to allocate (It's a single instruction to allocate stack space for any number of variables). If construction is expensive, then using a pool allocator won't help you any.

Share this post


Link to post
Share on other sites
Zahlman    1682
Quote:
Original post by RandomPixel
What about a "temporary variable pool"? For example a big struct with various of common variables. Then whenever you are going to use a temporary variable such as a for-counter or other things that only exist within the method, you can use a variable in this pool. The rule is that you will only use the pool within a method and not between another method (because that other method could be using the same variable in the pool). Maybe it won't improve the performance that much?


It will buy you precisely nothing for the reasons Evil Steve points out, increase the risk of subtle bugs in a variety of ways, and prevent writing recursive functions all together. A lose-lose scenario. (Don't worry; you're by far not the first to have thought of it. It just goes to show that "a little knowledge is a dangerous thing" when it comes to optimization.)

Share this post


Link to post
Share on other sites
Antheus    2409
Quote:
Original post by RandomPixel
Then whenever you are going to use a temporary variable such as a for-counter


Loop counters will hopefully be stored as registers.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this