Object pooling is an absolute necessity for performance in modern environments that remove all manual memory management in favour of automatic garbage collection. And it's still good practice to reuse memory when you do have some manual control.
Not many things will slow your program down (or make a garbage collector blow up) as effectively as alternately freeing and requesting tiny chunks of memory from the OS thousands of times a second.
Honestly this is usually bad advice nowadays, for a bunch of reasons:
-
Modern allocators do the same thing as object pooling internally, usually faster. They rarely interact with the OS.
-
A GC will do things like zero old memory on another thread, unlike a custom clearing function in a scripting language.
-
Object pooling breaks the generational hypothesis that most modern garbage collectors are designed around; it can actually make performance much worse. Most GCs love short-lived objects.
-
Object pools increase code complexity and are very error prone; when you add a new field you have to remember to clear it in the pool.
-
If you are in a non-GC language you probably want something "data-oriented" like a slotmap, not a pool of object allocations.
Having said all that, it still all depends on the language/VM you're targeting. The guy in the video clearly benchmarked his use case.
The guy in the video clearly benchmarked his use case.
This is the real answer in almost any scenario. Don't optimize without hard evidence.
-
