koobas.hobune.stream
Relationship between Events and Update()
Hello everyone, I'm starting to work with events but a I had a question that I a not seen directly addresses (and I apologize in advance if this question is strange or irrelevant).
-In terms of performance, is having a script that is subscribed to an event better or worse than say that same script checking for a condition in Update()?
--In my head, it would seem that the subscribed script would basically be waiting for a event every frame (or how would it know when the event was fired?). Or is the subscribed script just "available" and being subscribed just gives the event a memory reference to that method (and others)?
Any clarification is appreciated.
I found that honestly in some cases it doesn't really matter. However, I have had times where scripts in my update have slowed the game down a bit. Now sure why as the scripts really weren't that sophisticated. Never had it happen with a simple event.
That said, keep in mind "Events correspond to user input (key presses, mouse actions), or are UnityGUI layout or rendering events." It's constantly checking to see if the required trigger of the event has been triggered.
Not sure if this helped.
So, in simple terms: don't jam a program with Update() calls, and also don't jam a program with Events? Even if Events are less intensive - something like that?
I'm just thinking that for a system that needs lots of object's scripts subscribed to events, its really no better than a program with tons of Update() calls (since each scrip on an object is just waiting for something to happen each frame).
So, if a player was in a scene of objects, and 1 of the objects killed the player - it would be better to have that 1 object poll for player health then call reset methods in all the cubes (say those are in an array or something so you have reference to them) than it would be to have that 1 object fire an event since all the other objects are just waiting for something to happen?
I would think it would be worse to jam up the program with update calls than it would be for events. The program is always looking for events to be triggered. But the effect of those events don't apply until triggered. So while it's always looking it isn't doing much else.
With the update function you are always doing whatever is in the update. That means rather than just checking for activated events it's doing full statements and such. Almost like the effects are already triggered. And when there are hundreds of triggers going off at once it can boggle it up a bit.
So ins$$anonymous$$d you call them in events so they only trigger when necessary.
Well at least that's how I see it.
Interesting, so events still have less impact than say something like: (sorry about the formatting, I'm losing the fight to Unity's formatting structure)...
void Update()
{
if (condition is true)
{
call specific method
}
}
Yes because it's constantly running this statement at all times. Now because there's not much for this statement it's not gonna be a noticeable difference in most cases. Since the statement is stopped at the condition if it isn't met.
Essentially think of events as a statement stored to the side and waiting to be used. Unless it's something you need right away wouldn't it be easier and more efficient to stash it to the side until needed rather than carry it and make it a burden? This is how I view the difference between update and events.
"Yes because it's constantly running this statement at all times" -That is more or less what I really was getting at, I had thought that events were like updates in that they sat around going "Am I needed...am I needed...etc", but really its more like any public method in a script, it just is around until something references it. So ins$$anonymous$$d of the Update flow (code -> sees if it is needed) it would be more like (delegate that knows the code is needed -> subscribed code), where the subscribed event is allocated to memory?
And by the way, thank you for ongoing dialogue, really appreciate it.
Use events whenever possible. As the events are (or at least more likely to be) written in a lower level language they'll require less processes.
The difference will be mostly unnoticeable but avoidable processes should be avoided (without sacrificing some readability).
I see, if possible, could you take a look at my post above that quotes Foestar and see if I'm thinking in the right direction?
