x


Pooling object performs the same or worse than instantiate/destroy?

So I recently started pooling and recycling the objects I frequently instantiate, because I've heard multiple times both here and on the forums that it is better for performance. However, when I make a build with an FPS counter, the performance during heavy instantiation sequences is pretty much the same, or sometimes worse, than simply instantiating/destroying. Is this normal, or is the benefit of instantiating going to be more of a long run kind of thing as the garbage heap starts to fill up?

I wrote my object pooling script myself, mostly with inspiration from this example, except in UnityScript and with some minor tweaks: http://snipt.org/ylxo2 I don't really see anything wrong with it, but maybe a fresh set of eyes might see something.

more ▼

asked Feb 01 '12 at 01:32 AM

PrimeDerektive gravatar image

PrimeDerektive
3.1k 57 64 84

Well, for starters I wouldn't be using Unity's 'Array' class. It's terribly slow.

Feb 01 '12 at 01:39 AM syclamoth

Oops, I had the wrong link in there to the script I got my inspiration from, I updated it. I used Array because I knew it was for the most part the same performance wise as ArrayList, but I just noticed that script was using generic lists. Do you think that would improve a bit?

Feb 01 '12 at 02:14 AM PrimeDerektive

Well, I personally can't really help you with UnityScript optimisation. I don't really know much about that. I could help more if it were C#, I know that.

Feb 01 '12 at 02:30 AM syclamoth

Never use Array or ArrayList, Array is a good 30X slower than built-in arrays, and 10X slower than List (in general). Any reasonably-implemented pooling will always outperform instantiate/destroy. I don't see what the point is of your container object; there's no reason to parent pooled objects to anything.

Feb 01 '12 at 02:39 AM Eric5h5

Thanks Eric... List it is, then. The container is only to organize my scene view hierarchy when I play in the editor, more of an OCD thing.

Feb 01 '12 at 03:14 AM PrimeDerektive
(comments are locked)
10|3000 characters needed characters left

1 answer: sort oldest

The purpose of object pooling is not to instantiate objects faster, since it most certainly will NOT be faster. BUT, what an object pool does is LIMIT MEMORY CONSUMPTION. Think about it this way - normally you Instantiate and Destroy object. When you Instantiate an object, it allocates memory. When you Destroy an object, it will eventually get cleaned up by Garbage Collection. If you have a lot of objects being instantiated and destroyed frequently, it will almost certainly start triggering the GC which can result in frequent hiccups and freezes.

However, in an object pooling system, the object is instantiated, but never actually destroyed. Rather, it is de-activated and then later when another object of the same type needs to be instantiated, instead of instantiating it just re-activates the previous object. In many cases (particularly frequent calls to Instantiate) this can save tons of memory, and in the long run eliminate a lot of garbage collection.

more ▼

answered Dec 22 '12 at 12:38 AM

PhobicGunner gravatar image

PhobicGunner
1 1

(comments are locked)
10|3000 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Topics:

x1677
x764
x27
x19
x10

asked: Feb 01 '12 at 01:32 AM

Seen: 1159 times

Last Updated: Dec 22 '12 at 12:38 AM