[C++] Are memory pools still important?
Author
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?
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++)
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++)
Author
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.
Thanks again.
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.
Author
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?
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.
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.
Memory pools are also extremely useful on platforms like DS where there's limited memory available and fragmentation is a major concern.
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?
Quote:Original post by RandomPixelLocal 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.
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
