Timeline for Why should I always consider creating and using object pools instead of instantiating the new object on the fly?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 13, 2017 at 22:43 | comment | added | mrr | Alternatively just amortise the cost over time: if players can spawn objects, then create a pool of (say) 8, then when they spawn the 9th create another 8, then when they spawn the 17th you make another 16, etc., exponentially. Depending on the platform you can even allocate each of these in a single malloc. | |
| Sep 13, 2017 at 13:08 | comment | added | Luaan | @DMGregory In a typical GC environment, de-allocation is most of the cost; in a typical non-GC environment, allocation is most of the cost. Object pooling works great for both, they're really just two sides of the same coin for the most part. In the extreme case, old games used to be written with all the objects "allocated" from the get-go - very little or no memory de/allocation while the game was running. You didn't really use anything that wasn't "pooled" in some way. Since Unity uses a lot of real-time "metadata", pooling can help quite a bit - though it can also be trickier to implement. | |
| Sep 13, 2017 at 13:03 | comment | added | Ethan Bierlein | "For instance, if you have a game where player input dictates what prefab is spawned, then you may have no choice but to use the normal Instantiate call." - Not really. You could easily have multiple object pools for different prefabs allocated to the desired sizes at startup (or scene load). Or, if one wanted to make it, an object pool that stores multiple prefab types might also work. | |
| Sep 13, 2017 at 1:52 | comment | added | congusbongus | @corsiKa that would be an 80's era optimisation. Unity can just deactivate the prefabs in question, making its systems ignore it. | |
| Sep 12, 2017 at 17:00 | comment | added | corsiKa | So you just move your bullets somewhere safe while in the pool? | |
| Sep 12, 2017 at 11:05 | comment | added | DMGregory♦ | It might be worth mentioning allocation and garbage collection as major contributors to the cost of repeated instantiation & destruction. Generate enough garbage and eventually the whole game has to wait for the garbage collector to sweep it all up. ;) | |
| Sep 12, 2017 at 9:30 | vote | accept | Muhammad Faizan Khan | ||
| Sep 12, 2017 at 9:28 | comment | added | Kevin H. | Yes, instantiating frequently can slow your project down. As you saw in the video, you will have to code a bit more, but it is worth it! | |
| Sep 12, 2017 at 9:24 | comment | added | Muhammad Faizan Khan | "The act of instantiating and destroying are inefficient and can slow your projects down" . this is the reason? So it means that we have to code a bit more (like activate deactive, or set position of bullet again so we can fire again) | |
| Sep 12, 2017 at 8:52 | history | edited | Kevin H. | CC BY-SA 3.0 | added 301 characters in body |
| Sep 12, 2017 at 8:40 | history | edited | Kevin H. | CC BY-SA 3.0 | added 265 characters in body |
| Sep 12, 2017 at 8:32 | history | answered | Kevin H. | CC BY-SA 3.0 |