I’m not sure I understand what you, as a user, wants to gain from this object pool facility in factories. In the architecture, Defold consists of a number of “object pools”. We never allocate memory dynamically at runtime. Everything is very precisely allocated up front, acquiring a number of arrays with similar access patterns to make the CPU caches as happy as possible. You can think of this as the opposite of OOP and inheritance, it’s often referred to as data-oriented design. The good news is that this makes the cost of spawning game objects approach the cost of spawning particles, it’s really cheap. You control the “cache sizes” by setting different values in the game.project file, e.g. sprite > max_count. That value will define how large array we will allocate (once, when the engine fires up) for sprites. When you create/destroy game objects containing sprites, you will automatically get slots in these arrays, without needing to care. There is no GC happening in Defold at runtime, with the exception of:
- Lua. Defold does not do any lua below the user level, it’s only user scripts who use it. The Lua GC cost is more related to what your update() functions do, than the cost of creating/destroying script instances.
- Ref-counting for resources, e.g. textures. This is not really GC and doesn’t have a big cost, but related.
- 3rd party libraries, e.g physics engines. They typically have custom memory allocators to allow for OOP’y allocation (“new”) without paying the cost of general purpose dynamic allocation.
Have you seen any large cost associated with creating/destroying game objects? If so, it’s something we really need to look at, as it’s been designed to get rid of these costs.