koobas.hobune.stream
Call Update once per object vs Update all in a central script
Hi, I am making a block based game where different blocks have different behaviours and animations. I am handling the animations from within a script which means that each block has a copy of a script that animates it.
I read somewhere that there is some overhead in calling Start and Update because Unity gets the redefined versions I make through reflection. Would it be a significant optimization to make a master script for each type of block, and then have all other scripts register themselves there in a list that the master script goes through on one call to Update, instead of calling the Update function of 100 different scripts?
This way if a level has 200 blocks made up of 4 different types there would be 4 Update calls instead of 200 per frame.
Thanks!
I tend to keep as much as possible in a master script in my projects.... but that's just my style. I dont think it would make a noticable difference with proficiency if script is run on an objects or a masterscript. Actually i beleive Unity developers intended smaller scripts to run on objects. Actually there are situations where you $$anonymous$$UST run seperate script. There is no way to detect a Object's collision with out a script on it.
This should be pretty easy to test just in case, but I'm confident that your assumption is correct:
Assuming all the work being done is equal, 4 instances / method calls is superior to 200 script instances / calls. Whether the gains are significant is (subjective and) case-specific.
That's not to say you should jump on this paradigm 100% of the time. It's often a question of practicality, your preferred management strategy, and a dozen other considerations.
As your projects / objects evolve, you may encounter unforeseen complications regardless of which direction you take on this issue. In that sense, (and with the stated numbers of objects in your situation) the gains are relatively minimal. Choose the strategy which promotes the cleanest logic. You can refactor later if you must.
Nor are these strategies mutually exclusive. Having a collection of like-objects to iterate over is often a great idea, even if they have scripts with Update methods.
Best,
In the end I noticed that the frame drops where only noticeable when there were a lot of a certain block on screen, which has two moving parts each with one script and one Update call. So I decided to first merge these two scripts together which would achieve a similar effect, getting rid of one Update call per block of that kind. I don't know how to view the profiler while running on Android so I don't know the exact improvement, but the slowdown is no longer there! I will definately keep this in $$anonymous$$d if I need to squeeze some extra performance in the future. Thanks a lot for your help!
In the end I noticed that the lag was really only noticeable when there where a lot of a certain block on screen, which has two separate scripts that handle a translation of one part and a rotation of another. I decided that before testing this central script, I would merge these two scripts into one and see the performance increse (which would basically have the same effect of getting rid of one Update call per block of that kind). I don't know how to check the profiler when running on Android, but the slight frame drops I was seeing are definately gone now that I effectively halved the amount of scripts on screen for that block. I wil keep in mind that this optimization worked if I need to squeeze some more performance at some point, but I am happy with the level achieved now. Thanks a lot for your comments, they really helped!
