Q about llListen function, filtering and performance

I have a simple question really, regarding llListen and filtering. Say I have 5 people or so that I want to give access to a scripted object, and I'm using a llListen function. Is an open llListen function more efficient (lag wise, performance wise) than say, 5 llListen functions with filters based on user names? With the first method, I would still have to check the users in the listen event, obviously.

So, which is better for sim performance? If the second method is better, is there a limit to the number of function calls before performance suffers? (like if I want to have 10 or 15 users, etc.)

Thanks a bundle,
Mason

Received wisdom suggests strongly that one listen and internal filtering is more efficient on the sim than two listens or more.

There are, almost certainly provisos to that - you could write really shoddy code for your internal sorting for example but assuming you right reasonably good code that's the understanding at hand.

It probably makes sense too - if you create an extra listener the vm has to check if each utterance meets the criteria, so the more you create the more checks need to be done at that level, so *each* utterance gets checked more time, so bigger overall impact.

It is possible, however, that if you really, absolutely, postively must use channel 0 that, because so many things will trigger it, pre-filtering may just gain an edge. That said, open long-run listeners on channel 0 are almost always avoidable in my experience.

The best option for multiple users is to establish a 'touch-driven menu system' (touch and llDialog).

If you need to be always listening, then a private channel listen that is otherwise open is your best chance (llListen(chan, "", NULL_KEY, "", where chan != 0.

Thanks both for your reply.

I use touch driven systems when and where practical. For now, I make sure my listen filters use either owner or are on a specific channel, or both. Obviously, the more filters the better!

Unfortunately, both using a dedicated channel and requiring a touch sacrifice usability for performance. That's ok if the users are all moderately experienced, but less acceptable for newbies and the technologically challenged.

I'm glad I found this, because I was about to ask the exact same question. But now I can ask the followup question: Is there a way to measure the burden of an open listen? I might compromise by only enabling the open listen on channel 0 on sims that are lightly used and responsive.

In my opinion, a channel 0 listen is absolutely unacceptable under all circumstances. It does not take much to teach someone to type /1 before a command. In fact, many people just take it as part of the command. "Oh, I have to type /1 ao on...o.k.".

In fact, I distribute a notecard about the harms of public listens and advise all people to avoid buying scripts from people who use open listens Script lag may not be the #1 cause of lag in SL...but it is our responsibility to keep it low.

While I usually don't condone this sort of action, I've started working on setting up gesture packs for things I use that have chat functions; I used to have channel 0 listens on a typing display unit that I've been working on - Only because I had to act quickly when testing it, and having less to type made it quicker. Once I had it set up, I made a gesture that said the command on 0, but gave the actual command on another channel. Not a solution to the problem of inexperienced players, but a quick fix to avoid having listens on 0.

Gesture packs are definitely excellent benefits to a customer...and they're incredibly easy to make. I offer gesture-packs with several products I sell.

Ummm ... your use of channel 0, even if it is only the gesture packs talking to it, is still the same negative effect. In fact, it is probably worse now because you have gestures listening on some private channel and the listener on channel 0.

If I have missed something please explain, because from what I see all you have done is replace a channel 0 listener for an avatar to a private channel listener gesture and a channel 0 listener for gesture ...... *scratches head in wonder*

Gestures are triggered by the viewer aren't they?
If they are, then a gesture on channel 0 would not require a listener, just the viewer looking for the user to type a certain sequence which shifts the load from the sim.

The gesture would interact with the listener on a channel that wasn't 0. User types command, viewer triggers gesture, which speaks on channel xxx. Saves the user typing /xxx and doesn't need a listener on channel 0.

Don't forget that you can also simply create gesture hot-keys. That way, someone could simply press the F4 button, for instance, and draw a weapon...

In my opinion, forcing the user to adapt to compensate for the computer's deficiency is unacceptable. Computers work for us, not the other way around.

You've narrowed the problem to merely teaching people, so of course it seems easy. There are many other issues: suppporting people when they forget, which they will; actually getting the user's attention long enough to teach them to type /1; annoying users who forget, even when they recover immediately on their own; not losing sales by seeming too technical or unfriendly; not fitting seemlessly into a conversation, destroying the value of the object. I'm sure there are many others.

I've seen at least one pet that listens on channel 0, and produces smart (or smart aleck) retorts to various key phrases. It's hilarious, and people who see it love it. There is no way to do this without listening on channel 0, and in fact it's a totally open listen. It's much easier to teach the owner "Don't use this on laggy sims; don't use it for long in any event; turn it off any time there's a general request to cut back on scripts" than it is to teach everyone else "type /1 before everything you say so that the cute pet can respond to the things it recognizes."

I understand that the performance issues are a difficult technical problem. But the approach should be like any other engineering trade-off, which is to quantify them, simplify them in this case because there's no one single answer, and then make decisions based on those quantified conclusion on a case by case basis.

Can you please point to any authoratative source for this assertion? I'm pretty sure you're wrong, and that 5 listens with 5 specific targets would be more efficient in a public area where lots of people are talking.

Other posts above cite channel 0 chats as the root of all evil, but it's OPEN channel zero chats that are the bigger problem -- depending on the NUMBER of the objects doing this, and the number of people chatting, and the amount of code being run per "hit".

By OPEN chats I'm talking about those without an avatar or string specified.

Here's why I think so; and it's based on my assumptions about how the system is implemented. These assumptions tend to jive with experience and what I read in this forum (with the notable exception of the quote above). I assume that the system uses hashes to minimize looking for matching scripts, and the significant cost of listens is due not to this checking but rather to the scripts invoked as a result.

That is, the system is very efficient at figuring out WHICH scripts to invoke. The troublesome overhead is invoking each script and any processing the script does.

If this is true, then the way to asses a script's efficiency is to consider the following:

1) How many times will this script's handler be invoked
2) How much processing will this script do when invoked (including but not limited to "do nothing" cases, where after checking it does nothing)
3) How many instances of this script are likely to be within hearing range -- this is the "scalability" aspect.

Clearly, fully open listens on channel zero are the worst offenders, because for every sentence uttered the script is invoked. If the script adds to this problem by comparing the string against a lot of possibilities (or doing any other significant processing) before returning for each line of chat, it's a serious problem in any area where there is either a lot of chat or else a lot of objects that do this.

So channel zero chats are not necessarily evil, when targeted to a minority of the audience. Likewise, they're not so evil when the text is specified in the llListen() call, because the script will only be awoken when someone says that exact phrase (or, a phrase that hashes to the same hash key, which is rare enough to ignore).

Finally, to address another myth, not stated here but possibly implied. Scripts do not add to lag in response to motion nor do they affect the frame rate. When scripts cause lag, they cause scripts to be slow to respond. They do not affect other aspects of SL. Of course, this means that when you sit on a poseball, it takes a while for the animation to start. Or when you click a door, it takes a while to open. But it doesn't affect how long it takes for the world to respond when you move your avatar.

On the other hand, lag caused by too many prims, too much physics, too many avatars, etc., can contribute to script lag, up to a point. Scripts are given a certain fraction of CPU time. If the physics portion of the sim's work is low enough to keep up the desired frame rate, then any left over time is given to scripts.

Script lag is a server issue only and isn't related to client-side lag, which is caused by too complicated a world for the user's computer to display quickly.

I don't know whether script lag contributes to chat lag, and I suspect that it does. One reason is because sometimes I see obvious chat lag when there is no physics lag or frame rate issues.

channel 0 listeners are evil, if for no other fact you have to listen to 100 bubbleheads going
bling on
bling off
shoes red
hair black
ao on
ao off

CONSTANTLY!

i still use a single listener on a offset channel mainly becuase i dont like setting up (ie) 5 listeners (which is 5x the overhead) just to filter it out later in the event

Osgald, that's another matter entirely, but you're dead on.

5 listeners is not 5 times the overhead, unless your object is changing state frequently. If your object usually stays in one state, it's far less processing than a single listen. However, if you're listening on a nonzero channel it really won't matter. It is 5 times the hassle (or more) when scripting.

Something I should have mentioned above: the overhead to calling llListen() probably isn't trivial. Make sure your object doesn't change state frequently, if you use listens! Perhaps this is what you meant by "overhead".

You got it backward. The listener is now on channel XX. The command is /XX YYYYYYYYYY. The gesture is /YYYYY, and it replaces /YYYYY with "YYYYYYYYYYYYY" and also does /XX YYYYYYYYYYY. Since the listener is no longer on channel 0, it is in fact better. Gestures, as always are the text-activated events they always are.
Previous command: "HELLOWORLD"
Previous effect: Activates item.
New command: "/HWORLD" - And is auto-completing thanks to gestures.
New effect: says flavor text on channel 0, gives channel XX actual command, where the device catches the command.



I don't know quite how true this might be, but a once-every-few-minutes check for people in the vicinity in its immediate area would reduce some of the lag, I think... I may be wrong.

learjeff:

can you point to any authoritative source for your assertations? :) no, im not trying to be a jerk, i am really wondering. because the way i understand it....

it doesn't matter if the 'filter' is in the listen command or is inside the listen event. the incoming text still has to be filtered, which means, even a listen that only listens to its owner has to filter through all incoming chat to FIND those by its owner.

so i don't get the real difference between pre-filtering and post-filtering.


personally, i feel most listeners are evil. ESPECIALLY ao listeners. or even bling listeners. the purpose of having an ao (or blingy thingy, whatever) is to have it running all the time and only change its state (on or off -- or the shoe colour, whatever)... what? rarely! why have something listening 100% of the time so you can issue it commands 0.0001% of the time??

so, i like touch-activated things. i put my franimation override in a hud button. i touch the hud button, it turns on. i touch it again, it turns off. all with NO listening! wow!

even a touch-activated dialogue with listeners that you kill with a timer is good.


sorry, pet peeve, there.

i also wanted to ask, what about gestures? who or what or where do these things get parsed?? it isn't in any script, i can tell you. gestures are a part of the sl... world. client. whatever.

the beauty of gestures is, you dont have to use a channel number that people can remember! (i think 90% of all user commands go to channels 1, 7, 9, 13, and 99. :X ). instead, they can type in real TEXT commands to some astronomically huge weird number! just beautiful....

okay, shutting up now.

No, Bloodsong, just 30 years of programming experience. But your question is valid. Here is my thinking.

First, LSL is an interpreted language, whereas the underlying code and functions and server code are compiled (most likely C++). Compiled code is generally much, much faster than interpreted code. If anyone wants an explanation for that, just ask.

Second, the server does its filtering in an extremely fast way, handling all scripts pretty much at once (or really, in about 3 operations I suspect, as mentioned above). That is, rather than checking the filter for each registered listen, it does a single hash-and-index operation for all scripts. (The 3 operations being different KINDS of checks, not checks for different scripts -- and even then the 3 kinds could be collapsed into one hash, perhaps.)

With 50 "non-open" listens that don't match the criteria specified in the llListen() call, all are handled in one hash-and-index operation. (Or say 3, for different kinds, but let's forget that part for now). Whereas, if you have 50 scripts running with open listens and each has its filter, the server has to invoke all 50 scripts for each to do its own filtering.

Much, much slower in two ways: 50 times as many things, and each thing is slower because the interpreted code is slower.

BTW, this is similar to the argument about preferring llListFindList() rather than cascaded if-elseif sequences. The llListFindList possibly uses a hash lookup, in which case it's a very fast operation regardless how many elements are in the string. Even if it doesn't, if it acts like a string comparison in a loop, at least that loop is executed in compiled code rather than interpreted code. So, for greatest efficiency, you often want to use llListFindList() to see whether the chat string was of interest, rather than cascaded if-elsif.

The above decision depends on other things, though. If your listen is already well qualified and is rarely called when there's not an actual hit, the efficiency gain doesn't matter much. Especially if it's a rare event.

Again: the key to understanding efficiency is knowing how to count events. And the main difference between open listens and restricted ones is that for the latter, one operation handles all scripts. But for the former, each script has to be invoked. If there are N scripts, that's N operations rather than 1. This is a significant difference in scalability. In the latter case, as N grows, lag grows. In the former case, it doesn't. (Well, there is always some contribution to lag for a script even if it does nothing, but that's small compared to the listen operations we're talking about here.)

I don't know much about gestures, but no doubt the client initiates them. Whether the client does the 3 operations (initiating sound, animation, and chat) separately, or whether it just signals the server to do those, I don't know, and I doubt it matters much.

BTW, a restricted listen that stays registered is probably more efficient than code that re-registers a listen on each interaction. This is because each call to llListen requires allocating memory on the server, computing the hash string(s), and linking this info into the hash bucket(s). Now, I'm less sure about this than most of the stuff above, but my guess is this is more load than simply leaving a well-restricted llListen() registered.

Count the number of times your script is activated. Then look at what it does when activated. These are both literal factors in the mathematical sense, but the latter one is harder to assign a number since we don't know how much CPU time an 'if' statement takes, for example. But what you want to minimize is the product of these two things. And reducing the count should be the very first consideration.

And remember that a listen that doesn't match is NOT an activation. It's about as close to a freebie as you'll ever get in software. Registering the listen (calling llListen()) costs CPU time. But chats that don't match your listen do not cost CPU time for your script.

It would be interesting to compare the difference in efficiency between a well-restricted listen and a touch. Touches aren't free, you know. However, the client does most of the work, so I suspect that touches are more efficient, and I tend to prefer them too.

On the other hand, providing a good experience for the object user is very important, and IMHO more important than touch vs. restricted listen. Of course, touch is often a better experience for the user anyway. It depends on the function.

No. Which part of received wisdom didn't make sense?

The only way to test it is to go and set them up in a sim where you can see script times and test the different systems. My received wisdom is second hand, but is from someone that did just that and found that one listen has a lower overhead than several.

It's entirely possible that the situation isn't as clear cut as that of course, and a channel 0 open listen may well be worse than 5 filtered channel 0 listens, except I try never to use the channel 0 open listen, and even when I do filter it I filter for one person and usually only one utterance.

Whilst I agree with a lot of the rest of your comments, can I suggest you're hypothesising with little evidence? I'm certain there are all kinds of smart tricks that could be done to make things work better. The question is, were they, in combination with "how well do they work under the high loads you see in SL?" You may, of course, be correct and it's all done the best possible way on the vm, and it's possible it's changed in the background since the testing I was told about.

Sadly I don't have access to an empty sim and estate managers tools to do the tests necessary to confirm or deny either side of the speculation.

If the system is less efficient at filtering listens than scripts, then it would not have made any sense to provide arguments to llListen().

Correct, I'm assuming competence on the part of LL. That may be misplaced. My assertion is based on familiarity with programming practices for scalable systems and the fact that llListen() has arguments at all.

Furthermore, the simple assertion that a single unqualified listen is more efficient than multiple qualified ones is too general to be very meaningful. I seriously doubt that it's true, because if it was, there would be no outcry to avoid open listens.

Finally, it doesn't have to be done "the best possible way" in LL -- it only has to be done the "reasonably scalable" way.

It sure would be nice if there were tools to allow us to evaluate script performance, without being a sim owner.

Oops, I forgot to consider an important factor: whether most chat strings are actually "hits" -- that is, they make the script do something.

You see, with multiple listens, the code in the listen handler has to test which case was hit. Just as it has to test which case *might* have happened in the case of a more open (less qualified) listen.

My analysis above applies to the case where many chat messages do not match.

In the case where most messages do match, multiple listens would be less efficient, because the criteria is being checked twice (once by the system to see whether to invoke the handler, and once inside the handler to see which case occurred).

This is why open listens are obviously shunned, because most messages do not match. I say it would also apply to listens for a specific user (e.g., the owner). However, on nonzero chat channels -- especially unusualy ones like negative or more than 2 digits, it is probably the opposite case: most messages are intended for the object, and unless the owner is clumsy, most messages are valid ones intended to cause the script to do something.

Regards,
Jeff

another artist-not-a-scripter two cents here...


it seems to me... that ANY filtering of 20 chat messages from 20 avatars in channel 0 takes more resources than the occassional chat message on channel -94436276, no matter WHICH end is doing the listening.


however, i am now convinced that putting llGetOwner() and string matches in the listen arguments is faster than checking them afterwards.

but im still confused... if i want to listen for 5 discreet commands, do i use five listens on the same channel with different string filters? or is it not really mattering at this point?

If you specify a channel in the listen, the server is doing the filtering. If you don't, the script has to do it. This is equally true for the other parameters. If your point is that you shouldn't listen to all avatars on channel zero, I'm sure everyone would agree.

Yes, but of course you generally have to check the string anyway, to figure out what the command was.

haha, good question. Frankly, I usually don't bother, for simplicity. Here is how I think about it.

First, assume you're going to use one listen. Now think about all the cases when your script will get executed, including intended commands, commands intended for other objects, and background chat (if channel zero). If in most cases your script will only be invoked for actual commands, the single listen is best. If in most cases your script might be invoked unintentionally, then multiple listens would be more efficient.

Let's consider the case where on rez you select a random chat channel for menu and register the listens on that channel. In this case, I would register only one listen for all the menu commands, because virtually all invocations will be for valid menu selections.

Now let's consider the opposite case, where I'd register multiple listens. Let's say this object has to listen to everyone, and either listens on channel 0 or a low-numbered channel, for ease of use to the community. An example of this is the "show/hide" feature of many poseballs. Well, in this case it's important to register a listen for each command, because otherwise it becomes an open or nearly open listen. Many utterances would NOT be intended for the object (even if it's on channel 1 -- because so many huggers are, etc.)

Those are the two extremes. I think in general, for reasonably qualified listens (an unusual channel, owner-only, etc), a single listen is fine, and the difference between the two approaches isn't significant anyway so we go with simple is best.

However, whenever you feel the need for a relatively unqualified listen, needing to listen on channel zero for all people, then it's very important to carefully consider registering multiple listens, one for each specific command.

IMHO, listening on channel zero for owner is the borderline case, especially if there are lots of possible commands. I would probably register a single listen(), but I would be sure to use llListFindList() to see if the command matches and return immediately if not.

And as always, don't think about just one instance of your object, but the number of them that are likely to be found in hearing distance, and count them all when considering efficiency impacts.