Question by JasonBricco · Jun 05, 2014 at 06:02 AM · c#performance reflection events update function

Regarding Update() Performance

Hi all,

I've done a lot of research about Update() and the performance of it. And from what I can tell, it's not great. But I'm a little confused about why that is. I've seen information that almost tells me what I want to know, but not quite.

Is it slow because it runs every single frame? Or is there more to it than that? From what I understand, there's some slow-ish reflection happening to figure out that you defined the Update method in your script.

But does that reflection happen once at the start, then after that it's pretty much directly calling a function every frame? Or is there a significant overhead every single frame with Update(), that you wouldn't get if you did it say...

Make one update function that fires off an event, to which everything else that would have an update function subscribes to. That way you have one update function firing off an event each frame and then each script that hooks into that has a kind of update function through that event, without defining it directly.

Would that be faster than putting Update() all over, or would it be about the same?

Thanks in advance.

Add comment · Show 8

robertbu · Jun 05, 2014 at 06:50 AM 2

Should be quick to test.

JasonBricco · Jun 05, 2014 at 06:55 AM 0

Sure, but that would take a bunch of time that I could spend doing other things... and furthermore, it wouldn't help other people who might want to know the same information.

Oh well. I'll end up testing it tomorrow if no one provides an answer (going to sleep for now).

rutter · Jun 05, 2014 at 07:21 AM 0

If your Update calls are slowing down a game, it's more likely that the problem is with whatever you're doing in those Update functions.

Put another way: Unity is not always the most efficient engine, but you have to be pretty serious about optimization to do better.

rutter · Jun 05, 2014 at 07:32 AM 1

Unity can make use of reflection and other less-than-performant methods, sometimes, but it usually doesn't do so per-frame.

I wouldn't be surprised if a homebrewed Update routine ends up saving CPU time, but it would have other problems. The memory required to keep all of those object references will end up being non-trivial, and besides that it'll be on top of whatever memory Unity is already allocating for that purpose. It's easy to get caught up in algorithm analysis without considering the space/time tradeoffs in certain methods.

Or, put another way: if your own method uses a lot of memory, even though it seem academically faster, it may degrade memory cache performance and end up slower in practice.

In my experience, memory allocation tends to be a bigger problem than CPU use. Unless you're doing awesome stuff like traversing the scene graph ten times per frame.

I have sometimes written my own Update routines when I need more control over my components than Unity gives me out of the box.

robertbu · Jun 05, 2014 at 07:47 AM 2

I ran a quick and dirty test. It took about 15 $$anonymous$$utes to setup. I used empty game objects that are repositioned each frame. Using a PC build (don't do tests in the editor), the app first slowed down at 55,000 game objects. With a centralized Update() (no script on the game objects), it first slowed down at 90,000 game objects.

Of course you'll want to run a test on the specific platform you will be using. Results may be different for different platforms and different setups.

Show more comments