koobas.hobune.stream
Skip Awake/Start
Short question: is there a way to skip/ignore the Start and/or Awake calls on a freshly instantiated object?
(I know I could just simply not use Start/Awake at all and create an own function to call manually, but I am currently working on a generic Object Pool class hat is supposed to work with arbitrary Objects, so that is not the most desireable option)
I'm curious, why on earth would you want to do this? Not calling Awake() is like not calling a constructor - doing it on an arbitrary $$anonymous$$onobehaviour sounds like madness to me. And Start() is used to set things up right for the first Update() so again, why would you want to do that on an arbitrary class? I'm sure you have your reasons, it's just that I think it's going to be easier for people to suggest solutions if you show us your motivation.
As I said, I have a generic Object Pool class. I use it to not instantiate or destroy objects when the game is running. I create a couple of objects when the pool is created, and when I need one of these objects, I get one from the pool, ins$$anonymous$$d of creating a new one. Awake and Start will be called then, manually.
When I create a pool specifically for a single object(-type), this is not a problem, but I want a single pool-class that works with any Object (typeof($$anonymous$$onoBehaviour) for instantiate...too lazy to implement an own deep-copy functionalty for all object-types)
You can not call Start() by disabling the object after instantiation or even before (disabling the gameObject you instantiate, if you do it by copying). But AFAIK Awake is called immediately after the component is constructed. But from how i understand unity messages and how they were meant to be used, it should be OK (for correctly implemented scripts) to Only have Awake and Start called once, and rely on OnEnable and OnDisable for the reuse purposes... but I understand that this won't be the case in 95% scripts. And many scripts may not handle it correctly, when Start or Awake are called multiple times on the same script, so no generic solution would be acceptable here anyway. I know you asked a specific question which i cannot answer positively... So your options are:
Rewrite scripts you want to pool, or make sure they do the necessary initialization in OnEnable and OnDisable
Don't use GO Pooling. Is object instantiating itself (not object initialization in Start/Awake) really your bottleneck? It's very unlikely. Check again.
In the current project I am not really concerned with performance yet. I use the pool for messages that I display on screen, but I don't really save much performance compared to instantiating new messages and letting them delete themselves (One Instantiate per frame or less doesn't really change anything). This generic GO-Pool is meant to be a utility that I can use in all future projects, without writing a new one each time I need one.
That being said, Instantiate itself is relly slow (creating a new empty gameobject and adding the needed components is actually even a little bit faster than using Instantiate to copy a prefab), and efficient use of memory can (and will) affect perfomance significantly, especially when targeting lower-end machine or the mobile market.
It sounds to me like you're using GameObjects in a way that's sufficiently different to how they're designed to be used, that you shouldn't expect it to be possible to get it working with arbitrary $$anonymous$$onoBehaviours. So the way you're doing it (using an Init function to set the instance up each time you re-use it, and only pooling objects whose $$anonymous$$onoBehaviours have been designed this way) sounds like the right way to go. Rather than trying to call Awake/Start more than once, you just make sure that they only do stuff that's going to be retained throughout the object's various uses (eg hooking up any permanent links especially internal ones). You'll be able to use the object pool in future projects because you'll design those projects classes with it in $$anonymous$$d.
