Query project limits and current counts

We have implemented game object pools so we don’t have to factory.create() and go.delete() instances so frequently during play.

Sometimes the pools can grow considerably in size so we can have a lot of instances created (some being inactive). There is a hard limit for max_instances in the project settings so we are forced to bump this number up to reduce the chances of reaching that limit.

We can find out the limit from script via sys.get_config(“colelction.max_instances”)

The Question is: Is there a similar method we can call from script to determine the current number of instances?

We want to know determine when we are approaching the limit so we can either release resources from out pools, or fallback to a standard factory_create() and delete() methods.

Similarly want to be able to query the engine for the current amount of sprites, spines, collectionfactories, gameobject factories, colelction proxy, etc. Because these all have hard limits set in the engine and we would like to be able to track this during game sessions.

I do not know of a function you can call to get that number dynamically.

My question is if you actually need to do it this way. I know by experience you are used to pool instances in order to diminish memory garbage and allocation. Now all these objects are actually already pooled. (hence the max values in game.project) Using any kind of factory.create is therefor building up the objects all from pools and are impacting very little on performance and memory allocation.

Have you done a comparison on this to see if you actually need your own pool tech.

Still I can agree that it would be interesting to have access to the values (as the engine is retrieving them anyway when using the engine profiler).

Thanks for the reply, Andreas. That is good to know that there are optimizations on the engine side already.

We implemented the pooling after doing some profiling and finding big spikes when we delete and immediately create large batches of game objects; We hoped that having some objects readily available with the specific sprites/spines and all other sub-components would help with the spikes.

We have laso found other script-side optimizations that can be done during this time so maybe those will yield bigger improvements.

We are still very much interested in having access to those values as it will also be important for tracking purposes.

Maybe the spikes you experienced were cause by this?
https://forum.defold.com/t/memory-leak-when-spawning-new-game-objects-def-1983/2716/4

Because of this bug i too almost implemented my own object pooling but luckily it was fixed in the latest version.
Maybe you can try to disable your pooling to test if the spikes you mentioned are still there?

My current project for instance creates several hundred objects each second on 3 year old devices without any spikes since the bug was fixed.

3 Likes

As @Daggett said we had an issue when spawning large amounts of objects but that issue should be fixed. But maybe you have a lot of code in the init() and final() function of the objects, and in that case it might be more expensive to delete and create than it is to pool the objects?

You should also check the following answer from Ragnar regarding object pooling etc: Objects pooling for Factories (SOLVED)

Finally, if you need to get hold of any data that you can access from the profiler for tracking purposes then you should check out this post: DefPro - Accessing profiler data in Lua. Martin Noretoft from your office should already be looking into this if I’m not mistaken?

1 Like

Thanks @britzl, we will do further profiling once the script optimizations for the spikes are completed and we may end up removing the scrip-side object pools, as it seems that we don’t get a lot from it based on the linked posts.

I’m going to look into DefPro as it seems like it could work for the tracking we are thinking of. It is good to know that getting those values as a lua table is already in the plans (eventually) but DefPro might do the trick for now.

Thanks.