You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Object pooling is an optimization method for reducing the load on garbage collectors. Velcro already makes heavy use of pooling for internal objects such as contacts. This proposal extends this capability to user objects such as Body, Shape and Fixture to further reduce the load on the garbage collector.
The proposal is to add an interface to all 'poolable' objects that contain a Reset() method. Each class will be responsible for providing their own implementation of Reset to make sure they have cleaned their internal state completely. Each user object will be extended with a Destroy() method as well, that can be called by the user when the object is no longer needed.
The factory classes will then be made 'pool' aware and fetch one from the pool rather than create a new object.
Advantages:
Reduced load on the garbage collector since we reuse objects
Faster object creation as we reuse existing objects
Disadvantages:
If the user calls Destroy() on an object and uses it afterwards, it will cause havoc.
The engine will use a little more memory since we keep a small number of objects always
Misc:
I can make a setting for this behavior to be turned on and off. Should there be issues with bodies used after Destroy(), it can easily be determined by turning off pooling.
I will probably pre-load the pool with a couple of objects on World creation. This should also be configurable.
Any comments, improvements or votes (thumbs up/down) are appreciated.
The text was updated successfully, but these errors were encountered:
This is too much of a challenge to implement without any unwanted behavior. For now, the engine itself will pool aggressively for internal objects, but user objects will stay in userland. For large games, I suggest pooling bodies (etc.) manually.
Object pooling is an optimization method for reducing the load on garbage collectors. Velcro already makes heavy use of pooling for internal objects such as contacts. This proposal extends this capability to user objects such as Body, Shape and Fixture to further reduce the load on the garbage collector.
The proposal is to add an interface to all 'poolable' objects that contain a Reset() method. Each class will be responsible for providing their own implementation of Reset to make sure they have cleaned their internal state completely. Each user object will be extended with a Destroy() method as well, that can be called by the user when the object is no longer needed.
The factory classes will then be made 'pool' aware and fetch one from the pool rather than create a new object.
Advantages:
Disadvantages:
Misc:
Any comments, improvements or votes (thumbs up/down) are appreciated.
The text was updated successfully, but these errors were encountered: