How expensive are messages?

Questions
#1

Hi!

When I started with Defold I had to shift from the usual OOP to Defold’s “messaging” paradigm.

How expensive are messages in terms of performance?
Should you view a message in the same way as a method call in object-oriented languages performance-wise, or do you need to be more careful?

1 Like
I'm new to Lua, so I'm confused
#2

You should be more careful. Currently every message involves copying and serializing a Lua table.

2 Likes
#3

The message system is really flexible and powerful but can really impact the performance of a game , specially on collisions. I have a felling that either you guys will have to find a way to make it at least 2x faster (it’s somewhat fast already but…) or decrease the engine dependency on it on critical parts (parts that gets executed every frame)

#4

The message system itself is not slow at all, although it shouldn’t be confused with and used in the same way you do function calls. Some things to consider:

  • When you do msg.post("#foo", "message_id", { foo = "bar }) it will result in a table creation each time (ie the { foo = "bar" } part). If you do a lot of these in a frame you might take a hit. In such a case it might be worth to consider creating the table once and reuse it.
  • If you experience a performance degradation and you handle a lot of messages then it’s not the message passing itself that is the culprit. Start looking at your on_message functions instead. If you have a lot of code running in your on_message functions and you generate a lot of messages then the performance gain can probably be found in the message handling code. Read up on Lua performance tips for instance. Link1 Link2
  • Use the profiler to find where the engine is spending it’s time each frame! If you need to profile certain pieces of Lua code (or all your Lua code, take a look at ProFi.
4 Likes
#5

Thanks. I understand. My concern was the fact that you can only call a method on other object or component using messages (from what i understand) and that could cause a situation where it could get slow when you need to call a method every frame. I guess it’s just a matter of adjusting to this paradigm since i’ve never seen it in any engine, at least not used this way.

#6

If you have two different game objects that have such a tight coupling that you need to call a method every frame then I wonder if the problem can’t be solved some other way? It’s hard to discuss this without a concrete example though… If you could give me an example of something you had in mind then I could think about how that could be solved in a Defold friendly way.

#7

Well i’m just getting started with the engine so i didn’t come through any problems about the messaging system yet. I was just thinking about it because in another thread a user complained about too many messages when there’s lots of objects colliding and stuff. But that could be an isolated situation of his code and game after all.

#8

I think it could be me you are referring to. We did indeed have problems with a lot of objects colliding which caused message floods, but we have a quite rare case I would say, with a lot of game objects that needed to collide in certain situations and in other situation not. I still would like to see a possibility to “turn off” collision messages for individual scripts, but in this case we solved it by:

  1. Moving behaviours into lua-modules and creating single scripts that in turn loaded these modules, thus only having one script on game objects sensitive to the problem

  2. Better steering so that collisions became more rare. This had the added benefit of more realistic enemy movement.

  3. Switching between a static and a kinematic collision object depending on wether the enemy was moving or not

1 Like
#9

Yeah , it’s your case i was referring to. Turning off collision messages for certain situations could be a good option yes.

#10

An other option would be to have collision messages not be messages at all and instead have an on_collision function in the script. Then only scripts that care would be notified.

Collisions, just like input, is a bit of a special beast and should maybe be treated as such.

This obviously would be a breaking change, but it would make for imo clearer code and most likely better performance (a send collisions as messages checkbox in game.project could be provided for backwards compatibility). This is most probably why on_input isn’t just a regular message - to avoid the spamming.

2 Likes