Listen VS LinkMessage, the Truth

I have been experimenting with Listens and LinkMessages for over a week now, and my conclusions about the performance of the two when used for communication between two scripts might be of interest to a number of scripters:

1) LinkMessages are NOT faster than Listens. There is a delay of approximately 0.2 to 0.6 between the passing and the reception on BOTH.

2) LinkMessages are NOT more performant than Listens. Listen events are processed faster than the LinkMessage events ! I can get a listen to repeat the SAME CODE within 0.2 second, while this minimum delay is almost 0.3 second with link_message, nearly 50% slower !

And, of course; listens are filtered and selectable, which means that when you have multiple types of communications between your scripts (example for Chocobo: one for setting color and opacity, one for movement), Listens are less wasteful, one communication does not slow the other one by raising an event that needs ot be filtered out from within your event on the receiver.

I've always found linkmessages to be noticeably faster, but I haven't given it any formal testing.


Can you post more detail as to how you came up with those figures? Sim location, the LSL code used to measure the speed, etc.

I used my Unicorn as a testbed, I've ran it in many sims (sandboxes like Island Sandbox, Cordova and Goguen), LindenLands north of Goguen, residential Sims in the mainland, etc...

The code is basically one control/sit script with a fast timer that sends messages to other prims in the same linkset. It sends a number that corresponds to an animation step.

The receiving end extracts the number and applies the rotation that corresponds to this number (essentially, it is one line of code: llSetLocalRot(llList2Rotation(animation_list, animation_step)) ).

The main performance setting is the delay of the timer in the main script. With link_messages I can set it to 0.28 and the link_message events end up queueing most of the time, making the unicorn continue animating after it stopped moving. A better value I found was 0.3. With listens I can get it down to 0.25 and they never queue, they only queue sometimes with 0.2 and queue more with 0.15. Also with Listens I can multithread the listens, so I use two receiveing scripts and bring the timer down to 0.175 with no queueing ever. You cannot do this with Link_messages because it rises an event on all receivers, while I can send the message on a different channel and only activate the listen I want.

[edit] OK, I have to admit though that link_message tends to get activated faster after passing the message, about 0.2-0.4 second while listens get across in 0.4-0.6 second, after some more testing.

If the bold text is not a typo, there are two major things I'd like to bring up here:

1) To be fair, there are vastly better uses of llMessageLinked than "filtering out transmissions at the receiving end." While there are nearly infinite ways to do this, here are some examples:

- Make use of routing linked messages to specific prims
- Use a single list to define all of your phrases, via llListFindList. While this does do mild filtering, it chops calculation time to virtually nil.
- Listeners receive one variable (a string usually called "msg" by the receiver), whereas link messages send three: an integer, a string, and a key. This is very useful.

2) Listeners remain "on" unless shut off; link messages are on-demand.


... in my opinion, if you can use a link message as opposed to a Listener, do so. Period. The speed difference is pretty arbitrary, IMO - the performance difference on the sim (in bulk), however, is not.

Thank you for testing speeds, though.

This is a post I made in another Thread. I know the scripts I'm using are simple ones (so no "complex interactions" are tested to see if they change the overall performance) - but if you're looking for "raw" Listen vs. MessageLinked performance, this was a test for exactly that.

These are hard numbers. I've yet to see anyone else set up timing loops and post tests that result in hard numeric results calculated by the script itself during execution...

Sounds to me like lag is the factor to which is faster.

On another thought you could send linked messages to specific prims reducing spam.

The difference can't be explained by lag alone, I have been testing both versions simultaneously in the same sim :/

I could use multiple llMessageLinked() towards each prim, but the result is an unsynchronized movement (some prims moving at one time and others moving after a delay). If I use routing prims (which is not always possible) there is an additional delay. I don't really understand what you mean by the LinkMessages being "on-demand", how is that different from the callback in listens ?

Tread, thanks for the tests, but I'm using one-way communication, where the higher delay of listens is less a factor, plus I'm looking for higher maximum repeat rate, not smaller delay if there is little difference.

I just did a test with one box saying 100 numbers from 0 to 99 as fast as it can, and another box catching all these llSays, which took 14.8515 second. The same code with LinkMessage took 4.9508 second. For some reason the LinkMesg unicorn, in the same sim with same lag (or rather lack thereof) still runs slower than the Listen unicorn. Weird.

Correct me if I'm wrong, but using a link_message handler works a touch differently than a Listen in the sense that a Listener is "created" and remains as a running process even when it's not in use, whereas a link_message is only called by a function when used. As a result, link messages use fewer resources simply by the virtue of not being a constantly-running process.

Furthermore, an llMessageLinked function and link_message event script can call itself in the same prim - whereas an llSay/llListen cannot. This is very useful for linking several scripts together.

Hmmm, in my experience the listener is NOT a constantly running process like you seem to think, it is rather a monitor mechanism (the "mon" in "demon" for unix background processes) and is only run when the listen event is created by calling a llSay function. This is no different than calling the link_message event through the llMessageLinked call.

Also, I have a number of scripts that call the same prim, different script, through an llSay/listen Why do you think it is impossible ?

Link messages ARE slower. They are, they are, they are. Regarding listens themselves, I believe what Jerad above says is probably more or less accurate.

Tread you posted your test, but not my response. A send/receive ping pong is a valid test in a limited scope.

Try sending 100 messages in a loop via link messages directly, no pauses, and watch for 100 responses (put the trace in the link_message handler).

Do the same with llSays (100 says NOT in channel 0), with the trace in the listen handler.

Expand the test; send link messages from multiple sources to one object. Say, 50 from three sources. Do the same with listens. Listens will blow the doors off links.

The says will complete LONG before the link messages. I have validated this dozens of times, both in tests and in code that has been running non stop for months. In fact I logged in and checked it again, same story.

If you are sending lots of data rapidly, link messages is the intuitive thing to do, but it is a trap, believe me I know. Listens are the way to go if you're doing any real heavy lifting. Make your objects listening black boxes that process their own data (in lieu of a central processing mechanism that updates objects via links) and your system will absolutely run faster.

For a few updates here and there, link messages are fine. But if you need peformance for lots of data, nuh uh. I've developed two large game systems that move heaps of data and have run into this over and over for the past two years.

So to recap...

LISTENS ARE FASTER. LINK MESSAGES ARE NOT HIGHER PERFORMANCE.

Anybody that doesn't buy it, find me online, and we'll run the tests. You'll see that past a very limited threshold that this is indeed the case.

When deciding between using link messages and listens for communication in one related system, you need to consider more than just the absolute speed at which your stuff runs. Ask yourself: do you really need to do this as fast as the sim can possibly go? I don't care if link messages are slower for your script than listens, I still hold the belief that they'll give the server much less burden until you prove to me otherwise, especially in light of the recent discussion about 2 listens vs. 1.

So the question is not which is faster, but whether using link messages is fast enough. I'm writing a board game right now that (unfortunately) has to use tons of link messages to set textures on a lot of prims. An entire board update takes 10-15 seconds... but when it comes right down to it, that's perfectly fine. My players will see the board updating, so they'll know something is happening. It's a friggin board game, people can wait.

I don't need to be requiring the entire sim's attention just to squeeze a little more speed out of this game... remember that when you're pummelling the sim with listen events to pass piles of data a few seconds faster, everyone else's scripts are probably slowing down. I can only think of a few cases where communication like this would be time-critical.

Also, don't forget that the ability to send a number, a string, and a key can be very useful. llSay/Whisper is limited to 256 characters.

Any large scale test with LinkMessages is going to be scewed.
LM's & Chat are queued differently.
LM's adhere to the event stack size limits; meaning that if you throw 500 LM at the script all at the same time only about 90 of them will be queued and the other 110 will be discarded.
Chat on the other hand has an a queue that max's out around 600 -> 700

I ran the scripts below with [1, 2, 3, 4, 5, 10, 30, 60, 120] emitters; with only one receiver.

Results: (rounded off to 2 decimal places; these results scaled perfectly, regardless of the number of emitters (slaves))
Chat: 1 per 0.15 seconds
LM: 1 per 0.05 seconds

Test scripts:

//Master
float M;
float C;

integer MN;
integer CN;

integer num = 50;

integer chan;

integer L;
integer T;

default
{
    state_entry()
    {
        chan = (integer)llFrand(1000000.0)+1;
        llListen(chan,"","","");
        llSetText("Chan = "+(string)chan, <1,1,1>,1);
    }
    touch_start(integer a)
    {
        L = llGetNumberOfPrims();
        T = L * num / 4;
        if(T>200)
            T = 200;
        //Capping the timer as no test has produced a time greater then 100 seconds.
        llSetText("Started\n" + 
                  "Chan = "+(string)chan, <1,1,1>,1);
        llSetTimerEvent(T);
        llResetTime();
        llMessageLinked(LINK_ALL_OTHERS,num,(string)chan,"");
        CN = MN = 0;
        C = M = 0;
    }
    link_message(integer a, integer b, string c, key d)
    {
        M = llGetTime();
        ++MN;
    }
    listen(integer a, string b, key c, string d)
    {
        C = llGetTime();
        ++CN;
    }
    timer()
    {
        llSetTimerEvent(0);
        llSetText("Chan = " + (string)chan+
                    "\nChat = " + (string)C + "    Received = " + (string)CN +
                    "\nLink = " + (string)M + "    Received = " + (string)MN,
                     <1,1,1>,1);
        if(C == 0 || M == 0)
        {
            llSetTimerEvent(T);
            llResetTime();
            llMessageLinked(LINK_ALL_OTHERS,-num,(string)chan,"");
        }
    }
}

//Slave
default
{
    link_message(integer a, integer b, string c, key d)
    {
        a = (integer)c;
        while(b<0)
        {
            llSay(a,(string)b++);
        }
        b = -b;
        while(b<0)
        {
            llMessageLinked(1,a,(string)b++,"");
        }
    }
}

Ultimately chat is more reliable because it has a huge queue. My tests indicate it's 3 times slower. These results are reproducible.

I will believe others test results when they post their test scripts.

And that's a key insight for new scripters.

Kind of hearkens back to the old IBM "two-second" rule-of-thumb: As long as you do something visibly update-ish every two seconds or so, you can generally spend what time you need, getting the job done. Neglect visible updating for more than two seconds or so, and users begin to wonder if they've been forgotten.

Or so the old adage went.

Of course, credibility got stressed a bit when Microsoft started setting their thermometer-style "progress bars" to race to the 100% mark and then sit there for an hour...

== danny d.

I'm referring to commands passed with llWhisper/llSay/llShout versus a listener in the same prim; llDialog is a different matter entirely, since it requires user input. When I want two scripts to pass large amounts of information to one another, I'll do it through a link message, not a listener.

We're going to have to agree to disagree on the behavior of listeners as running tasks. I will note that passive listeners flip an object to ACTIVE, so...

Exactly. If for no other reason: llWhisper() and its "Cousins" are all limited to a 255-character string length. MessageLinked() does not suffer from this limitation, AFAIK.

As far as running tasks:

When there are no messages being sent on any channel (including no avatar chat on channel 0), then the impact of a Listener on the Sim is probably close to 0.

But when is that situation ever true? I'm sure it is a rare occurrance - so in most situations (especially when there are any Avatars around to observe or interact with your object), Listens will be draining Sim resources "constantly".

Think about it: the Listener needs to somehow be "attached" to the message buffers - and will be invoked any time a message is sent by any object. It will then be filtered based on channel, key, string, etc.... But all of these operations take effort. Even just having the Listener "attached" to the message buffers (i.e. active in a script) increases the memory that the Sim must use - because the sim has to track all of the listeners; and know how & when to invoke them.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Heres another thing to consider --Listens also might require or string parsing to get and seperatethe required information or maksure that the listens are ot oveheard or so that they do not interfere with other objects of the e type.

Personally I've found say response time to be unreliable. No formal tests, but under laggy conditions I've had it take a second or two for a say to be registered while link messages continued to work well. It's a matter of needs, really.

Yes, one message, a big pile of data. I have conceded that. In fact I use it all the time.

But it doesn't work for rapid update of data. Like bullets or any rapidly changing value. You don't send four bullet hits in one message, you send it in four.

We can go on about the mechanics of LSL, but it's easy enough to prove with either of my before mentioned tests.

Think we're just talking two different definitions. One, moving a pile of data at once (links) as long as you don't have to move a lot of piles fast.

The other, rapid real time updates. Link messages are just too slow. Keep in mind the structure involves incoming data from an external source, not just one compound object pushing around some data.

Tcoz -

You wouldn't want to use Link-Messages for Bullets anyhow... Trying to manage a bunch of items like that as linked prims would introduce all kinds of unwanted complexity.

Look, the bottom line is that the situations you keep talking about are complex and unique - and the performance depends on a lot of variable factors in those cases. And we have no sure way of knowing if parts of these complex code interactions are what's causing the slow-downs - it could be the message-handlers themselves; or it could be the way they're having to be processed, due to the different formats that are used. Any good programmer should remember that each complex chunk of code is uinque; and testing is the only reliable way to optimize each unique situation...

See Strife's earlier comments about the message queues - in a situation with rapid-fire information coming from a lot of sources, that may be very relevant.

However, most of the time, coders in SL are looking for a quick/simple way to pass information about moving a prim, or animating textures, or setting off a particle effect. In these "simple" cases, the "pure" performance of the LinkMessage vs. llWhisper should be the guide. And tests from several of us posting to this thread concurr that LinkMessages are inherently faster in "simple" or "stock" cases.

And all of these discussions neglect to talk about the impact that the Sim has on the script; as well as the script's impact on the Sim.

...Having said all this, Tcoz, I'd be interested to see this test-code you have that shows LinkMessages performing more slowly. I may not believe it; but I am curious.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

I should say about my test that i was running it in a sim that started out with an fps around 1000 (i was running it in the preview grid). The server was also running 2 other sims. Time Dilation was around 0.85 and stable. The main contender for sim cpu time was a couple schools of fish (and i think one of my test scripts accidentily caused some cross talk with one of the schools as they attacked my test object & me; but when i removed my test object they went away).

having about 220 slaves (and about 7 masters) in the sim dropped the sim fps to about 300 after the tests were run. Never did i run two tests at once.

My only thought on my test was if having them linked effected the master for the chat.

Post your test scripts. No better way for us to know what your data means.

One other thing to bear in mind in all this, is that if you really want or need to you can pass TWO strings in each link message. The key part can be cast as a string.

I've use it sort data sensibly one string being the message, the other the coding for which group it belongs to.

But if I just had a huge amount of data to dump across I could do it in half the number of link messages compared to the number of says.

What can I say /shrug. I'll use listens when I need lots of data moving fast in my games, because I have proven countless times that they are faster for what I need. All this guessing at the mechanics of SL is pointless. As is apparently two years of coding LSL. What do I know.

Thanks for the implication Tread, in bold, regarding "any good programmer". I won't forget it.

Later for this forum. I stopped posting here for a long time, now I remember why.

I never talk to myself to move my arm or leg.
Its easier and more logical to use internal functions for that.

/ Max

Ah, yes, I'd forgotten about that one. In SL, our users are jaded to expect lag, so we get more like 3 or 4 seconds before they start wondering

I think the TRUTH is that listeners creates lag and link messages does not. If you want to create lag use listeners if you can avoid it avoid it.

Sim FPS with 0 listeners: 996
Sim FPS with 6400 listeners (64 listeners in 100 cubes): 906

Test done in Eclipse.