Why is this even in Unity still? I ran into a question on Answers and someone answered a question from nearly 5 years ago… So this made me check if it was even in Unity still, it is (2017.2).
Why is this still available? Is there some benefit that makes the con of being nearly 400 times slower, acceptable?
I haven’t heard of anyone using this in years, it makes sense why old versions of Unity uses it - to maintain old projects. But why is this not depreciating? I can’t think of any use case for it that makes it acceptable.
In my (not so important) opinion, I honestly believe this should be depreciated in newer engine versions, unless there’s some major pro to using it that makes it acceptable to make your entire game with it. Because lets face it, in my opinion, new comers who come across this ‘SendMessage’ thing might not understand how slow it truly is, and will think that’s what you’re supposed to use, so I think Unity should depreciate it or at least change the Summary of it to let them know how slow it is and to try GetComponent instead.
What’s your take on SendMessage for NEW Unity versions, I understand why it’s still on 3x, 4x, etc.
But today this should be completely avoided (unless of course there’s a major advantage for using it), but I don’t see ANYONE use it unless they just don’t know of the Alternatives.
There are probably some situations that it’s still useful. Lots of languages have things that aren’t ideal, but are necessary when you get to some really hard problems.
I assume that it, or something like it, is used internally for stuff like Animation Events, which are data driven and can’t know about things like identifiers defined in your code.
Also, speed isn’t everything. Yes, it’s really important in some parts of our code, but in other code it just isn’t that big a deal.
Also also, the GetComponent() approach doesn’t achieve the same thing. SendMessage() calls the identified method on every MonoBehaviour on the GameObject in question, not just on a specific one. You could replicate that with GetComponent(), but it’s not as trivial as you may think, and may indeed end up being more than “400 times slower” than a straight function call.
@wccrawford1 Sorry, tired lol. Well not just tired, every time I’ve read it, I’ve always read Depreciated (I have a problem with that), I see words at times that just don’t exist even if I read the same thing 10 times back to back. Not sure if there’s a real medical reason for that or I’m not paying attention, it does get quite annoying and happens a good 20 times a day minimum.
@angrypenguin : I suppose that does make sense, didn’t really think about Animation events, I just fear that a new comer will read all these old help messages from old posts and think this is what to always use. When I first started using Unity it was quite popular, every single tutorial or walk through I went through always had Send Message for everything, haven’t seen anyone use it in years however.
The benefit is “Don’t fix it if it ain’t broken”. If you don’t like it, don’t use it, but if you NUKE it, then you’ll break somebody’s project.
I also vaguelly recall actually using this. I highly doubt it is actually 400 times slower, by the way.
If the memory serves me right, somebody used it in their RTS game to broadcast notifications to units and it ended up being more convenient/easier to use than the “proper” approach.
I believe I used it to notify all the components on object about something happening. You know, like a callback, but without the glue/initialization code. Ah, right. It was “OnDamageReceived” notification. It worked like that: if an object had an AiController notification, it would react to it. If it had any other component with similar method, it would react to that too.
And yeah, as @angrypenguin said, it is very heavily used by animation events.
@neginfinity I agree.
Well I read somewhere and they said @Eric5h5 did some test a few years ago or something and it came out to like 400 times slower. (I can’t validate if that test happened or not), I just know it is slow lol.
I mean I don’t have a problem with it in Unity, I just didn’t understand why it was still here, now I know (learn something new every day ). I mean at least they could update the Summary just letting (new) users aware of this… I’m just looking at this from the prospective of a new user coming into Unity, who knows nothing about coding and instantly does Send Messages because a lot of old tutorials mention it. I just think there should be an at least a minimum updated Summary for the call so new users are just at least aware of it’s performance impact.
Me personally I don’t care if it’s in it or not, just didn’t realize what was really used for, figured it was just an old Method call and that was it lol. But now I realize the importance of it and I agree it should stay, but they really should adjust the Summary for new users.
These days I tend to use ExecuteEvents to do the job instead. It’s faster and type safe.
But despite all its flaws, SendMessage requires significantly less boiler plate then any other method. And it can also call private methods. If you don’t have control over the class you are calling into, SendMessage can be a decent option.
Agreed I believe to have heard, in several performance optimization Unite talks, that Unity uses SendMessage to notify components for various things, such as OnCollision/Trigger events, which is (allegedly) one reason why some systems are slow.
But don’t you think you could just use static Methods instead of SendMessage or ExecuteEvents? Never heard of ExecuteEvents so I can’t say much about that. But doesn’t SendMessage technically do the same thing as a Static Method call? I mean wouldn’t it just be easier to do SomeClass.SomeMethod();
Being SendMessage calls all the Methods of the MethodName on every script on the object… I’d assume just using a Static would be better?
That statement doesn’t make sense. A message sent with SendMessage is received by all components attached to the object. Meaning it requires instances and “this” being available. Static method has no access to “this”, and can’t notify components attached to this particular object. Now, there was a pattern in couple of places within unity, where an object had a global singleton notifier event of something, but this is not what send message does.
A static method call does exactly what it says. It only calls one method, and that method needs to be known in advance. It comes with all of the conditions that being static imposes.
SendMessage, on the other hand, finds all MonoBehavour components on the target GameObject, looks at each of them to see if there’s a compatible method with the specified name, and calls each one it finds. Each method called is called in the context of the object it’s called on.
Ah okay I understand it more now - sorry I never really used Send Message much, I started off when i came to Unity with it as I figured it was faster being a Unity thing.
But quickly after a few weeks of using it I went to the more common used route.
But thanks for the info guys.
In pseudo code SendMessage basically does this. (Forgive me for being too lazy to type out the reflection properly).
void SendMessage (string message){
foreach (Component component in GetGomponents<Component>()){
if (component.GetType().GetMethod(message) != null) {
component.GetType().GetMethod(message).Invoke(component);
}
}
}
ExecuteEvents does this
void Execute<T>(Action<T> action){
foreach (T t in GetComponents<T>()){
action (t);
}
}
It’s very easy to see why ExecuteEvents works many times faster then SendMessage. But it’s also possible to see the occasional spot where SendMessage might come in handy. It’s a rare use case, but not a completely obselete one.
There’s static method and then there’s non-polymorphic method.
Static method has no “this”, and is essentually a function within class body. A non-class function restricted to class scope. It is “public static void something()”.
Normal method has access to “this”, but is not overriden in the children. If a child class implements the same method it shadows the original method in the base class, but functionality of the base class remains unchanged.
And then we have polymorphic/virtual methods. In this case each child can override functionality of the method, and that functionality will be used in instances where the method was called in the base class.
SendMessage allows calling any non-polymorphic method by name. Most likely using reflection.
ExecuteEvents abuses polymorphic behaivor but introducing bazillion interfaces. Also, its calling pattern is incredibly non-obvious:
public static bool Execute(GameObject target, EventSystems.BaseEventData eventData, EventFunction<T> functor);
I remember being rather anoyed with SendMessage when learning Unity. Most of the beginners books and tutorials used it but then said it was slow and you shouldn’t really use it but didn’t give an alternative. Just teach me the proper way to do things from the start.
Sure, the point was to clarify that there’s a clear and important difference for someone who didn’t already understand that, not to provide a reference on how methods are called.