Sign in to follow this  
SymLinked

[C++] Are memory pools still important?

Recommended Posts

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

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