Are Unity planning on improving SendMessage?

I like to use the Event model in my games, but SendMessage seems really basic and from what I read online it's not that performant either. I've been using the CSharpMessenger from the Wiki and it does a much better job.

I'm confused as to why SendMessage is as basic as it is when you consider that listening for and broadcasting events is a fundamental process for most game developers.

I always try and avoid using third party scripts when possible so I can be sure my code will work with future iterations of Unity. Does anyone know if Unity are planning on improving SendMessage in the future releases of Unity?

I don't know how SendMessage() works internally so I can't really say for sure, but here might be a couple of reasons it is slow. It takes a string as its input and then calls a method. That isn't ever going to be very fast compared to directly calling the method. I don't know how it iterates though all the `MonoBehaviours` on your GameObject, but that involves gathering all the scripts on your GameObject then checking each one to see if it has a method that matches the argument.

Will Unity update it? Well, they probably won't slow it down. :) I doubt that it is a high priority because there are other more efficient ways of event handling already. You can try using C# events too.

public class EventClass {
    event Action trigger;

    void Fire() {
         if(trigger != null) {
              trigger();
         }
    }
}

And it really depends on how often you call it. Using it for something like damage is usually fine because it won't ever be called more than once or twice a frame every few seconds. Using it to handle something like input handling would be a bad idea on the other hand.

I haven't noticed any major drawbacks with SendMessage, but I can imagine it being somewhat slow for continous calls. However now that you mention it, another message handling technique could be a hybrid where clients make use of SendMessage and the host make use of delegates. That way it becomes easy to opt out of events, and performance cost is bundled to instantiation/reactivation. You also get rid of the i`f (!enabled) return;` guard you sometimes need to put, and you can even delegate events to non-component classes.

class EnemyTrigger : MonoBehaviour
{
    event Action OnEnemyTrigger = delegate() { };

    void AddOnEnemyTrigger(Action action)
    {
        OnEnemyTrigger += action;
    }

    void RemoveOnEnemyTrigger(Action action)
    {
        OnEnemyTrigger -= action;
    }

    void OnTriggerEnter()
    {
        // Imagine other code that would 
        // check tags or layer or something            
        OnEnemyTrigger();
    }
}


class ExampleHandler : MonoBehaviour
{        
    public GameObject prefab;

    void OnEnable()
    {
         SendMessage("AddOnEnemyTrigger", OnEnemyTrigger); 
    }

    void OnDisable()
    {
         SendMessage("RemoveOnEnemyTrigger", OnEnemyTrigger); 
    }

    void OnEnemyTrigger()
    {
         Instantiate(prefab, transform.position, transform.rotation);
         Destroy(gameObject);
    }
}

Although I much more prefer the slim variant with SendMessage.

class EnemyTrigger : MonoBehaviour
{
    void OnTriggerEnter()
    {
        // Imagine other code that would 
        // check tags or layer or something            
        SendMessage("OnEnemyTrigger");
    }
}


class ExampleHandler : MonoBehaviour
{        
    public GameObject prefab;

    void OnEnemyTrigger()
    {
         Instantiate(prefab, transform.position, transform.rotation);
         Destroy(gameObject);
    }
}

Dont know about performance of SendMessage but i've been using for some time and it works perfect to me to avoid lots of listeners to be hearing i use

GameObject.Find("MyObject").SendMessage("Method",params);

this one is for multiple listeners on a GameObject-(edited thanks to Eric)

GameObject.Find("ParentOfMyObjectsOfSomeType").BroadcastMessage("Method",params);

hope it helps you on someway