Game Development

Honestly this is usually bad advice nowadays, for a bunch of reasons:

1. Modern allocators do the same thing as object pooling internally, usually faster. They rarely interact with the OS.

2. A GC will do things like zero old memory on another thread, unlike a custom clearing function in a scripting language.

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

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

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