I mean, just Instantiate and Destroy. It’s 2015, I’m sure it’s not going to kill anyone’s computer.
Is there something I’m missing, or is this more over optimization from people too smart for their own good?
Is there something I’m missing, or are you complaining about how other people code? No one is forcing you to object pool.
3 Likes
People are mostly using object pooling on mobile, where it does make a good difference.
The garbage created from constantly destroying stuff can add some pretty bad micro stutter once it gets gc’ed.
I was able to make my frame rate way more stable by using object pooling.
Though this is per game and per project, it is not always needed or even a good idea for some games.
I’ll be using object pooling on my PC-only game that I’m working on. It will only have about a dozen or so objects on screen. Is it overkill? Absolutely. Why am I doing it? Because I plan on having future projects that will likely have thousands of objects. Self-training, if you will, since object pooling is something I don’t worry about in my day job. Easier to debug off-by-one errors and such when my object pool only has 12 items as opposed to 12,000 items.
You could equally ask whether texture atlassing, static batching, or keeping mesh vertex counts low is “overkill”. Like object pooling, none are necessary, yet they all (potentially) improve performance. Do them if you want, don’t if you don’t.
It depends what you are pooling and how often you are creating and destroying really. I definitely recommend pooling if you are going to frequently use and dump a particular object. It’s not that hard to create a pop push routine and in the end it may actually save you troubleshooting and lines.
This is an EXTREMELY basic and not at all real code example but it could literally be this easy.
method Push(object) {
ResetItemVariables_if_needed_blah_blah;
Array/List/Whatever.add item;
}
method object Pop {
if (Array/List/Whatever.count != 0)
return, remove item, whatever
else
create new object;
return;
}
objectType localObject = Pop();
no longer need object...
Push(localObject);
I’ve used object pooling on PC games for some things. It really depends on how ‘heavy’ the objects are in terms of components and hierarchy, because the more you’ve got then the more work Instantiate is doing to clone them.
1 Like
On Mobile it is very important, but it depends on what you are doing. In one of my games I create 20 sprites at the start of the level and they work on it and then I restart the scene. Object pooling wouldn’t really make much of a difference.
On the other hand, if I would be creating objects after the scene is loaded, I will use object pooling. You should always avoid instantiate after Awake/Start() on mobile.
Since it’s so easy to do, and it offers a good performance game, I’d still do it for desktop games. Gives you more room for other things and it is such an easy fix. Leave that room for things that are much more difficult.
Well, be careful - you can still end up with ‘recycling bugs’ (state not reset, coroutines left running, etc), and having pools that are larger than necessary will cause GC to take longer because it will have more objects to walk through. But I guess those aren’t that big of a problem.
Don’t fix things that aren’t broken. If your frame rate is consistent and sufficient for your needs forget pooling, or optimisation of any sort.
My C# background is a billion times better than my Unity. I know in C# pooling is a pretty common thing even when dealing with small values. Resetting values shouldn’t be that hard.
But, at the same time if you don’t run the risk of needing to pool then don’t bother I suppose. If there’s any chance of you increasing your game to where you might need a pool you’ll regret putting it off.
Even if it’s not necessary, it’s a good practice to be familiar with. I assume you’re still learning C#, and if you’re still learning, you should be getting used to common practices such as object pooling.
A lot of people say not to worry about optimization unless your framerate is sucking. Would you not worry about the structural stability of a house you’re building until it’s falling down? If this were the prevailing professional opinion, good framerates wouldn’t be possible. A lot of modern performance comes as much from optimization as CPU improvements.
I think a better caution is to not optimize in ways that hurt the readability and flexibility of your code. I think being familiar with basic ways to optimize your code without sacrificing anything else is much better than later discovering that you have to go back and retroactively optimize when framerates start stuttering because the garbage collector is being fed constantly.
Memory management is easier in C#, but I really don’t think it should be altogether ignored.
3 Likes
I think it’s a super simple concept. I just think it adds needless lines of code. I like short methods, clean code, descriptive names, readability like “If (hasBanana) Say (“I am a monkey.”);”
I guess it’s just a passing thought, I could easily write a little pooler with funny names.
Your pooled should be totally self contained. Once built you use the same number of lines to Instantiate and destroy.
You can make it a self contained object with static Spawn and pool methods, so really once setup your code will look more or less the same.
Yeah, on the setup end it could be more lines but now that I think about it, since everything’s a game object, there’s no need to write more than one object pooler. Just different variables to set how many of each type you want. Even that can be adjusted on the fly. As usual, it’s simpler than my initial impression led me to believe.
Ya I got a game object that in the inspector I can drag in prefabs, set the amount for each, and I also got a option to let the pool expand or lock it to only a set number. I also implemeanted this with the re orderable list in unity this way I can change the order of the pooling in case 1 object in it relies on others.
After all of that I got it setup as a singleton with a static pool and static spawn method.
In the future I’m dumping the singalton in favour of just a static method of finding a named pool manager. This way I can have multiple pools and destroy one I’d needed.
I want to create an object pooler called PoolParty.
Well I’m with superpig on this one. Even for mobile, it can create all sorts of problems which a single instantiate can cure. If you’re working with large projects, large pools are a pain to maintain, consume stupid amounts of ram (for example if you have 100 different types of object) and so on. Instantiate for simple scripts on simple objects is the way to go if you don’t need to spawn many, often.
So it’s about shoes that fit, really. AFAIK unity 5 optimised instantiate and destroy a bit (but that might also be in 4.6) and I’m hoping Unity will continue optimising Instantiate to the point where it’s quite viable for a lot of things.
Bullets and so forth - do yourself a favour - pool 'em 
FWIW - we pool projectiles and effects and instantiate/destroy just about everything else
2 Likes