koobas.hobune.stream
is gameObject.Getcomponent an expensive call?
I'm working on my second iOS project, and I have a few destructible environment objects I'm working with. Each part of the destructible object has to have a script reference to every other part of the destructible object. I have a few more of these destructible objects to code, but I wanted to stop and make sure that calling gameobject.getcomponent("name of object") wasn't too expensive (it's currently only being called in the start function). Basically, for this object that breaks into 4 pieces, each of those 4 pieces has a GameObject.Getcomponent to find the script of the other 3 pieces in the object. Should I be worried about this clogging up my iOS game?
Any help is greatly appreciated :D
Sussy
Try this thread
http://answers.unity3d.com/questions/15451/which-is-faster-gameobjectfind-or-gameobjectfindwi.html
Sounds like you are doing that in start and cacheing the hook which is the way I usually see it recommended. You did put your example in "..." as if it were a string so I'll add this from here:
Do not use the version of GetComponent that takes a string. When you call GetComponent without a string the return value is already of the correct type and you can access your custom variables and methods. If you call GetComponent("TargetScriptName") you will get your script, but the compiler doesn't know what type it is so you cannot access your custom variables and methods [unless you manually typecast]
Just a tip worth remembering.
I'm using C#. I'm having issues using the getcomponent without using the string version. I currently have it like so, glass1Script = glass1.GetComponent; but it's giving me an error. Before I was using the string and then casting it and it worked, but I figured there was an easier and more efficient way to do that.
and I would look at the unity scripting reference, but the c# pages are broken since they updated the site
The syntax for calling a typed reference to a component in C# is as follows:
ClassName variableName = object.GetComponent<ClassName>();
Those damn parenthesis!!! I've always had to make a reference to the object, then a separate reference to the scripts on those objects... this saves SO much time!!!
Would you please mark this as answered? I think the tip Tricky provided resolved the last issue.
"Premature optimization is the root of all evil"
Don't bother cacheing a reference to your components. It will maybe save an unnoticeable time, but it will be a horrible mess if the component gets destroyed, or changed.
I don't think you can equate caching a component to writing optimized and difficult-to-maintain code.
Unless "changed" means "replaced", this makes very little sense in general. Aside from the case of your component being destroyed (which you would check for identically?), seeing dozens of *.GetComponent<Something>().* polluting a function declaration is almost unreadable by itself.
Caching is slightly more error-prone, slightly harder to read, and slightly more difficult to change. The error part is you can forget to initialize it, and as the answerer notes, changing the object and forgetting to update the reference. I've done that. While getComponent(x) may not look pretty, it's more readable than a variable componentReference.
If the component is't used much, caching may even make you run slower because of the extra variable (but either way, it's going to be barely noticeable).
Yeah, those are fair points and I'm conflating readability with eyesores.
I think the only "running slower" I'll agree with though is my lifespan after scrolling past an ocean of UI component references on my way through someone's menu system.
Not really. If you're that concerned about it, you can assign the resulting component to a variable so it can be directly addressed. That will save you about three flops. I really doubt you would ever notice any difference unless you're addressing it every update or something.
