llListen and causing lag

Every so often I run across warnings against listening on the chat channel, that it will cause lag. The page on http://www.lslwiki.net/lslwiki/wakka.php?wakka=llListen is pretty easy to understand. But just let me see if I get this right.

Assume I have an object (say a visitor list) which should like to listen to commands like
'say list' and 'reset' - in that case I would like to listen to a 'low channel' number, say 4. I want all in a specific group to be able to do it, so I can not filter on name or key. But, it seems like setting up two llListen calls would be better than one generic:

llListen(4,"",NULL_KEY,"say list";
llListen(4,"",NULL_KEY,"reset";

at least that puts some of the filtering into the sim engine rather than in my script, which I presume is better?

(in the listen event I then need to check group, and which command was actually issued)

The 'chat channel' usually refers to channel zero - which is open chat. As you can imagine this channel can pick up a lot of... chat.

I've seen conflicting opinions about whether its best to filter in the llListen set up, or in the listen Event handler itself, so, for me the jury is still out on this one.

Steering clear of channel 0 is the first and biggest thing to remember.

In any case, no one wants to hear you talking to your devices.

I script my plants - is sort of ok to talk to my plants ....

as low traffic channel as possible,
as specific (pre-filtered) as possible,
as as little time as possible.

those are the general rules.

your listens look fine, just remember that they will be case specific.

oh and get rid of the NULL_KEY references, "" works eactly the same in this case, and saves you ~70+ bytes of program space in this case.

there was an examination of the order of filters on the sim, in a post here somewhere but IIRC it breaks down to the order of things being filtered is:
channel (are we listening to this channel )
self (objects can't listen to themselves)
range (is it <=20m distant from a say, etc)
key (are we filtering for a specific key)
name( are we filtering for this name )
exact phrase ( are we looking for a phrase, and does this match )

the server can do these tests faster than the script VM can because it occupies a layer below it and doesn't need to be translated. obviously the sooner something filters out, the less processing it has to do, so filtering by channel and key is best, exact phrase is least effective, but at least removes the extra processing at the script level which is slower than the sim handling in general.

Script lag is not really part of the overall lag picture. Every thing else comes first. Scripts get a piece of what is left over. Therefore, scripts don't slow down rendering, rezzing, physics, etc etc etc.

If there is not enough time left over for scripts, then they can cause each other to run slowly because they compete for the same cycles.

The BIGGEST reason to keep stuff off Channel 0 is the annoyance factor. Channel 0 is for chat. Commands to objects don't need to be scattered to every avatar. Make objects listen on another channel. And respond with llInstantMessage, or if only the owner should be talking to the thing anyway, use llOwnerSay.

No need to clog up the chat channel with stuff like this.

hmmmmmmmmmmmm.

Amusing for a Saturday night.

Latte has a question answered by Starbuckk.

Now if we could just get Cappuchino to chime in

I mentioned this in another thread but it bears repeating.

script instructions themselves will not cause sim lag, such as saving creating or modifying variables. however anything that affects other parts of the engine WILL, including listen filters on busy channels, each time something is said every filter is tested and reduced to determine if an active listen gets triggered.

there's an order, something like, channel, self says, specifc key, specific name, phrase, all reducing to the exact listen that gets the info passed on.

if it's an unfiltered listen on channel 0 (no key, name or phrase) that means all items get passed to the scripts, but it als means that fiter keeps getting tested for every thing said, which can be a lot of traffic on public... all adding up to extra stress on the server, which equates to lag

Per Kelly Linden 11/13/07:

I agree with the last part, but not the first part.

Scripts in common objects that listen on channel zero cause all other scripts to be slower to respond, because they spend time handling messages that they end up ignoring. This is wasteful and stupid. The fact that we sometimes hear someone say "show" or "hide" is minor in comparison, IMHO. For unusual objects, it's no big deal, but for common objects in popular areas, it's a big mistake.

Of course, scripts that only listen to owner don't have this problem, and the annoyance factor is the reason not to use channel zero. On the other hand, "bling off" is such a common convention, it's unwise to make blingy jewelry that does NOT respond to it. (It can also respond on some other channel like 1, for the benefit of owners of class and distinction.)

Void summed it up pretty well. The server code is a LOT faster at filtering out messages you shouldn't care about than your code could possibly be. When thinking about how efficient a script is, figure out how many times it gets "awaken" to handle some event -- even if it does nothing with the event. Awakening it best to avoid when unnecessary! And LSL code is many, many times slower than similar logic in the server. (Somewhere between 20 and 200 times, as it turns out.)

On the other hand, if your script handles 30 commands, it's probably unwise to register 30 handlers!

In this case the number is 2, and I think registering 2 handlers is best, but probably no big deal since it's not on channel 0 anyway. I can only guess where the tradeoff point would be for how many commands one might register separate listens for. In those cases, I generally opt for simplicity and just avoid aggregious practices like listening unnecessarily on channel 0.

missed distance