Search Feedback


Object pool built into Instantiate

Profiling & Optimization



I often hear that you HAVE to use object pools to get decent mobile performance. I went to an official Unity talk about Unity 5 and they had a whole session on how important object pools are.
So wouldn't it be great if it was built into Instantiate?
In the end, even with zero setup, Unity could internally Instantiate prefabs, keep them in a buffer and dynamically reuse them, until memory dictates the oldest start being GC'ed.

You'd also need a few utility functions for manual pre-allocating of some prefabs.
A very simple way of setting the reuse condition (offscreen, time alive etc), or an interface to implement your own.
The profiler (or somewhere else) could benchmark typical game scenarios to get ballpark pre-allocate figures for different prefabs. This could be a simple benchmarking component you add to each level/area, so differences can be measured and configured separately.

Comments (8)

  1. D55ad35e517c4779ba5d66e598355525?d=mm


    Apr 30, 2018 12:06

    It's worth mentioning why this is a great idea and what would make it worth doing:

    If you were to implement your own object pooling, as is suggested by unity themselves in games where you expect to spawn/destroy objects frequently (which is very likely to happen!) the hardest part to handle is the initialization of the object. Our common understanding of objects is that they have a construction process which is where the properties of the object will have default values, and other states will start in their default state. When you implement your own object pooling, you have to - against your common understanding of objects - ignore the normal initialization of the object and implement your own initialization layer on top of the usual construction process. This can grow increasingly difficult, the more complex the object becomes.

    There are internals which allow the "resetting" of objects to their default states, however these aren't accessible to us because we aren't able to construct MonoBehaviour objects, this is reserved to the internals of Unity, particularly to Instantiation.

    So, unity are best-placed to implement object pooling for two reasons:
    - they are able to "reset" objects from within the internal processing of objects
    - they could naturally call the correct behavior methods, such as Start/Awake in the same way that we would expect objects to normally call them

    Upon doing this, there is no added complexity to the developer as developers would treat pooled objects in the same way as un-pooled objects. Unity could even implement a feature like this under-the-hood so that we don't even know objects are being pooled, adding even less complication and removing limitations.

  2. C6eab14093842069a1022321436dcd39?d=mm


    Feb 27, 2016 09:06

    Some type of automated pooling option would be great.
    It doesn't have to be built into instantiate but it should be built-in to unity.

  3. D21b0457600588ab018a680e598d0ea7?d=mm


    Dec 21, 2014 08:20

    As a new Unity user having spent 5 months using "instantiate" and "destroy" only to discover I have to go back through all the code regarding particles, projectiles and AI in order to optimize for memory use and performance because I used these "bonafide" methods? This seems like a level of abstraction that would be addressed by the game engine.

    At least create suggested alternative methods such as "spawn" and "despawn" that are specifically noted in the documentation pages of those scripting calls. The pooling video with the guy coughing through it seems like a bandaid.

    Almost every game will have to deal with these performance bottlenecks at some point - many unity users never know why their game performance is affected because of this "trade secret". Without this projects have to get pretty deep in order to feel the pain of the issue. It would be a huge burden lifted to address this - and probably short work on your end to do - and please include networking calls when you make this fix.

  4. 3646d1ad11bf99d7147f28896da0cef1?d=mm


    Sep 13, 2014 21:08

    A colleague of mine and I discussed this exact sort of feature. He suggested a checkbox for all prefabs to "Pool this prefab" with an optional "Number of instances" to predefine. Leaving it at 0 could simply tell the engine to dynamically manage that prefab's pooling.

  5. 4c8697c572e57e5f9c81689ad7e1756f?d=mm


    Aug 23, 2014 18:53

    It would be very nice to have a native version of what "Pool Manager" does. Essentially, Unity should call a Spawn method every time the gameobject is being (re)instantiated, where you can "reset" your components.

  6. 607ce6a9c9e2262a248c6fddde99f5ef?d=mm


    May 16, 2014 03:42

    Superpig: Yep, but Unity could automate most of this too. If you run a profiling tool to get a typical scenario for that area/scene, it could also be monitoring the variables which changed. eg position, health etc.
    If that wasn't enough a simple utility to manually tick which components/variables to reset on reuse would do the trick.

  7. 1b1faa4f671a1854c421043c1049ce2f?d=mm


    May 10, 2014 22:18

    It will be good to have this.

  8. Ec8340606ac48db877bbdf7510a43e2c?d=mm


    May 10, 2014 11:45

    You'd still need to implement all the 'recycling' logic yourself, though - if Unity were to do it then they only way they'd be able to do it safely would be to completely reinitialise the object, which is usually a large part of the cost of Instantiate in the first place.

Your opinion counts

Help us make things better. Share your great idea for improving Unity or vote for other people’s.

Log in to post a new idea








AI & Navigation






Asset Store


Asset Store Publisher






Cloud Build




Docs & Tutorials






Game Performance Reporting


















Profiling & Optimization