I’m considering implementing an object pooling system into my program. My program does not use any custom classes, but there are many (perhaps hundreds of) instances in my code where a blank table is created using {}, briefly used as an array, and then forgotten. Would I gain a significant advantage in efficiency by creating an object pool for these blank tables?
1 Like
No, most likely. Also, never optimize before having actually taken measurements and determined there to be a bottleneck.
5 Likes
I’d rather use object pooling, when the creation and deletion of said object is expensive.
If it’s not the case, I would keep an eye on memory leaks and keeping the number of objects stable.
Here’s some tips I find useful today, because I underestimated their power:
-
Do block (New scope)
- Garbage collector cleans what has been left unused
- No need to overwrite outer scope variables if you want to reuse names
- “Private” variables now assigned to functions in the outer scope
do
--code
end
-
Weak tables
- Garbage collector cleans what has been left unused
- No need to explicitly dump a key or value
setmetatable(t, {__mode = "k"})
The garbage collector is meant to be your friend, label your trash.
4 Likes
On my PC in Studio, I was able to create 100,000 blank tables in around 0.01-0.02 seconds (a single frame at 60fps is approx. 0.017 seconds). I would be amazed if the creation of blank tables ever had a performance hit on your game.
Object pooling is really useful if you have to create a lot of instances though. For example, if you are creating a BasePart for an automatic machine gun, then it would be good to reuse the projectile instances.
4 Likes
Object pooling can also be good in network cases, where you keep the desired network owner ready for interaction, and so prevent network owner settlement during the recycling of the objects, like projectiles (although, for the player, may include security problems).
1 Like