In this video I explain Object Pooling and show a demo measuring the memory usage and FPS compared to simply creating and destroying objects. The performance...
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.
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.
This is the real answer in almost any scenario. Don’t optimize without hard evidence.