Objects pooling for Factories (SOLVED)


#1

Here is a initial thread:

It is very strange that, in view of the current approach to the creation of objects, you can not use the factory as object pool.

It’s “must have” for any game engine. The implementation in the engine architecture is not difficult, i think.
And in the editor, it can be presented as a checkbox "objects pooling " and two fields ‘minimum cache size’ and ‘maximum cache size’

It can greatly increase productivity out of the box, reducing the load on the gc.


Object pooling example?
#2

Many users already think that factory component work as object pool.
It would be a great feature!


#3

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.


Hands-on volume/playback control of individual sound instances
Object pooling example?
Query project limits and current counts
#4

Hmm, or are you interested in having all the spawned objects be automatically deleted when the game object containing the originating factory is deleted? Like ownership?


#5

Oh!!! Thank you for the reply!
It looks like we have a great misunderstanding here. I’ve thought that any object is created dinamically.
Can you please add this explanation to manuals? Because first thing i’m currently doing is a creation of a pool for bullets, sparks, etc. (i came to Defold from AS3)


#6

Yes, great idea! @sicher could you do this? I just asked @britzl to modify his crazy bunny demo to do dynamic spawning/despawning, so now we can put my explanation to the test! He will probably post numbers soon.


Memory leak when spawning new game objects (SOLVED)
#7

Wow! It’s just WOW!!!
As I understand it’s entity component system when all components pre-cached - it’s really cool! I didn’t know it.


#8

I really don’t remember some information like this somewere in documentation (but I read it all)
On forum I found only one place when you give advice to use tabels for object pooling Object pooling example?


#9

Some slides I did for an internal presentation about Defold and performance. Really sorry about the shitty visuals. :smiley:

The first image is a scene graph where the color means different “types”.

Then this is what happens when you apply classic OOP on it, with a base class Node, virtual update functions, etc. The trace means function-calls on the CPU. Notice how the trace grows with the number of instances.

If we look at the memory, it’s even worse…

This is how we do it, how clean and beautiful is that?? Happy caches! Constant trace, contiguous memory.


#10

It’s a Data Locality http://gameprogrammingpatterns.com/data-locality.html - cool!
As I understand you already has all components and empty entities. And when object created you just set component links to entity - just a simplification of course .

But i don’t understand your advice in old forum topic.


#11

So, Factory is working like this (added a “store”) :slight_smile:


#12

The old advice was unfortunate, I thought it had to do with the particular game design in that case and not performance, as there is no need for lua object pools for perf reasons. I’ll update that post to reflect this.


#13

In your architecture used all that I really love =) (Data Locality, ECS, and without thoughtless worship to OOP =)) )
And now I like Defold even more!
Thanks for your explanations.
I hope this topic help other users to understand how engine works.

(and yes, would be great to add this explanations to http://www.defold.com/manuals/introduction/ with @Sublustris image (with a storage image much better) )


#14

3 posts were split to a new topic: Memory leak when spawning new game objects