However using that code requires considerably more implementation work and plumbing for every new message.

I have seen multiple posts on the forums suggesting SendMessage is extremely slow but no information in the Documentation and no concrete examples of performance differences between SendMessage and direct calls.

I do not want to implement public properties for calling components because during development I constantly delete and recreate objects and this mechanism is complex to manage.

I want a notification system where the sender needs to know nothing about the receiver and this code seems perfect.

SendMessage more than likely uses Reflection, which is probably why it is so expensive. I made a very simple NotificationCenter that might suit your situation. It does the minimum amount of casting/unboxing/boxing and is super simple to add new event types. All you need to do is add a new enum. The post with the sample code and details is here:http://forum.unity3d.com/viewtopic.php?t=40311&start=15#249309

I've seen your other post which is what prompted me to post this one. You code isn't a million times for complex than the one on the wiki, but it is definitely more awkward to work with hence I'd prefer to use the Wiki one if possible.

The one on the Wiki does need a few changes to work on the iPhone but I now have it working.

Would love an answer from Unity on whether or not SendMessage is implemented via Reflection and if it does are the reflection calls cached or are they made every time?

I noticed that the Penelope same is using SendMessage, so Unity must think its suitable for use on the iPhone.

I noticed that the Penelope same is using SendMessage, so Unity must think its suitable for use on the iPhone.

Thanks

Click to expand...

You should realize that "relatively expensive" is not always a problem. If you use a SendMessage every once in a blue moon to notify scripts of a certain collision for instance, it doesn't matter that SendMessage is more expensive than direct calls. However, if you program your game to have large numbers of SendMessage per frame, you are bound to run into problems on the iPhone.

Optimization is not about avoiding expensive code. It's about avoiding expensive code where it matters.

No real difference than characters; sure skin deformation is a more expensive, so you simply reduce mesh complexity, bone count and weight influences. That and fewer characters on screen at any one time.

I do understand all this. My coding experience goes back to the C64 and TRS-80 so I understand about optimizing my code and the impact of small delays when executed multiple times.

What I don't understand and would like to learn is how much slower is it. All i've seen so far is statements that it's much slower. Is it 10ms rather than 5ms on an iPhone 3G? Does it use reflection? If it does is it on every call.

In order for us to make intelligent decisions around flexibility over performance we need to understand the specifics. Would really appreciate a comment from the Unity Dev's.

If I was at my home computer I would throw together a quick test. Anyone care to see how long it takes to do n SendMessages vs n direct function calls? A few simple configurations would get a definitive answer quickly rather than speculating or waiting for a Unity dev.

Again, would appreciate a post from a Unity internal dev team member on this one. I don't think anyone else could answer it for sure.

If it does use Reflection, then shouldn't that mean the Asset Stripping feature which is a major benefit of the iPhone Advanced version cannot be used? It states clearly in the 1.51 manual that Asset Stripping it not safe even at the base level if Reflection is used. It makes no mention of SendMessage.

You know, if you just made a test script that sent a bunch of messages and timed it, it would take less time than you've spent on this thread. In fact, I got so annoyed that I went and wrote your test for you. The results:

There's your answers: (a) Direct function calls are an order of magnitude faster. (b) SendMessage doesn't use reflection. (b) Call optimizations only work on function calls (which is sort of obvious now that I'm typing it out).

On the iPhone a thousand SendMessage() calls performed in a loop will take 1/30 of a second (so one SendMessage takes 0.0000033333 second), while a thousand function calls take 1/200 of a second.

So -- like others already told you -- native function calls are faster, not so much faster that it really matters unless you use them near-constantly. So use the NotificationCenter script already.

Sorry if I annoyed you. I was simply asking for details from Unity devs who moderate these forums for support reasons how their code actually worked. Performance was my main interest, but we still don't know how it is implemented under the seams. I didn't think asking for clarity would have annoyed anyone.

I didn't attempt to time this myself because I didn't understand what the impact of SendMessage would be on the timing. Many people have posted on this forum that a SendMessage would be received on the next Update cycle rather than the current, which makes timing it pointless. In fact if your frame rate is 30 frames per second no matter how many calls you push at the call it should complete them in 1/30th of a second (so long as its not a million). Even if its one. Also, by nature SendMessage must be asynchronous whereas a direct call will wait for a return.

Thanks for going the extra mile to implement the code and time this. Given your results for SendMessage was 1/30th of a second suggests this was because of the fact it is sending Async calls into the next Frame update. If you send 1200 you will probably find it takes the same length of time.

Volunteer ModeratorModerator

I haven't seen anyone post that SendMessage would be received on the next Update, and if they did, that's quite wrong, and doesn't even make any sense.

When running benchmarks, I use a substantially large number of iterations and get the average of several runs, since I've found that execution times vary somewhat.

So, on my (rather old) machine, a loop of 5000000 SendMessage calls, using an empty function, takes 9.872 seconds. A loop of 5000000 direct calls (using a cached GetComponent) takes .024 seconds. Therefore, direct calling seems to be about 400 times faster, although considering that the loop itself takes up some time, it's probably more than that.

That is, of course, a highly artificial benchmark. In real-world situations, it still makes sense to use SendMessage if that suits your design, and occasional SendMessage calls won't cause any noticeable performance issues. But in a situation where a large numbers of calls is needed, then yes, direct calling would be much faster, assuming you're using a cached GetComponent and not using it repeatedly (which is probably at least as slow as SendMessage).

Wow, that sure is a big difference. With a performance difference like that it will definitely be worth the extra overhead of not using SendMessage for my message passing system (it uses lots of messages).

I did a lot of searching and research on these forums before posting this. I found quite a few references to SendMessage being Async. It kind of makes senses given it isn't necessarily a single function call since it will call the named functioned on ALL MonoBehaviour scripts attached to a GO.

I did a quick search, and here were just a couple of threads that mentioned that SendMessage is received by the GO on the next frame:

Volunteer ModeratorModerator

I did a quick search, and here were just a couple of threads that mentioned that SendMessage is received by the GO on the next frame:

Click to expand...

Mistaken, I'm afraid; not sure where that idea came from. It's not like SendMessage is physically sending a message that actually travels to other components and takes time to arrive. All it does is go through the attached components, finds matches of the desired function, and executes them. This is very easy to verify:

If there was any sort of "delay to next frame", it would print 2, 1, 3, (or perhaps 2, 3, 1) but it doesn't; it prints 1, 2, 3. It would make some game logic very difficult and prone to breakage if there was any kind of async operation here. Hope this clears things up.

In my testing it's 9 times faster on the desktop, and 32 times faster on the iPhone. (It's possible the results are very different with Unity 2.6, but I'm using Unity iPhone almost exclusively, so this is all I tested.)

After testing this yesterday I added the NotificationCenter to my project. By decoupling it simplifies my code. If I need to optimize, I can.

Volunteer ModeratorModerator

Yeah, that was with the Unity 2.6.1 editor on my G5. With Unity iPhone 1.5.1, building to my iPod 2G, I get 11.20520 seconds with SendMessage and 500000 iterations (dropped from 5 million so it won't take so long), and .01510 seconds with direct calls, which is 742 times faster.... In the iPhone editor, I get .73935 seconds with SendMessage, and .00095 seconds with direct call; 778 times faster. Maybe my methodology is bad--I'm just using an empty function as the target, the idea being that I'm only timing the function calls and not what the function does--but that's pretty consistent given that the two environments are quite different.

I have Event system for you (aka Antares Events Manager). My system is completely constructed on auto-generated Delegats (and Custom Delegats too) and five times faster than Messages.
1 000 000 calls in my case: 0,14 seconds. About 7000 times per millisec.
Messages: 0.7 seconds. About 1400 times per millisec.

The system uses Generic classes which will be accessible in Unity iPhone 1.6 but I can fast correct it for 1.5.1

The description is a little obsolete. Since then I have strongly expanded a functional of my Events System.
Sorry, but right now the new description has no English translation yet.

Antares Events Manager is fast, flexible, user-friendly and stable code, which can work in any dotnet languages and even with non-monobeh classes.
It is very convenient way for communications between C#, JS and Boo scripts.

For reduction of size of the occupied memory and increase in speed of operation of the application, I often use it with the classes inherited from nothing or from UnityEngine.Object

Why not do the housekeeping of getting the calls of getcomponent up front in a loading page then the variables are setup for communication?
Consume memory statically instead of memory and time dynamically....

To leave a note on the gravestone: C# events sure have its reason for existing, but the are to be taken with a grain of salt. You have to be extremely careful not to introduce memory leaks, which is particularly easy with events. There are tons of threads about this issue in various C# corners ^^. You could easily write your own, typesafe replacement of sendmessage which also caches all reflection data and thus is not noticable slower than the usual method call.

What was said in the thread above, that SendMessage would compete with method call is highly questionable, unless Mono does some very aggressive optimizations. I rather believe what Eric said, that it is about 400 times slower, which is the usual overhead of most kinds of dynamic method invocation, not only SendMessage.

I'm not sure I buy that memory leaks argument. Any message-passing system that doesn't crawl the object graph on every call is going to require some reference to the receivers. But if your objects are MonoBehaviours, you have a very convenient place to unregister for the event: the OnDestroy call. As long as you deregister at that point, you have no leaks. This seems like a small (and easy) price to pay for a strongly typed, fast, and built-in decoupling idiom.

I've just spent most of the day developing my own message-passing system, which has some nifty refinements when it comes to scoping of messages (both into channels such as "Game" or "UnitTest", as well as by the scene graph). But compared to .NET events, it has some serious drawbacks too. I'm on the fence at the moment — I might throw that out and go with .NET events instead. With a bit of support code for finding the right publisher(s), it could be really nice.

I'm on a windows surface, so those numbers are quite high haha.
But it doesn't seem nearly as slow as some people make it to be here.

I was in the middle of writing my own messaging system, which uses reflection to look through all the class's methods, and stores them as a delegate for later use.
I might still consider it because SendMessage only accepts 1 argument, but if SendMessage's performance has been improved I might just use that.

Volunteer ModeratorModerator

That's not really a good idea; it's far better just to use a custom class. For example, if you wanted to pass a string and an int, make a class that has a string and an int, and pass an instance of that class with the desired values.

Oh thanks ! so i will do that !)
But must i use again send message or direct call for class ?
I try to send a class by message but i get unexpected token when i replace String for class in my function.
And excuse me cause i'm a absolute beginner; must i use a public or static class or maybe a public static class ?

Digital ApeModerator

Using sendmessage once per frame really can't slow down any game, it's just absorbed into background noise. The problem is when you start having a lot of them per frame. You can't do that on mobile and expect great performance. But one here and there never hurt anyone tbh.

It's probably bad if you have a lot of different components on an object though.