Clarification needed

The Wiki says:
So if i have 10 objects, that I am willing to listen to, is it better to code:

llListen( Ch, "", key1,"" ); 
llListen( Ch, "", key2,"" ); 
...
llListen( Ch, "", keya,"" ); 
CODE


or

CODE

llListen( Ch, "", "","" ); 

    listen( integer channel, string name, key id, string message )
    {
        if("" == id) return;
else if(key1 == id) DoSomthing();
else if(key2 == id) DoSomthing();
...
else if(keya == id) DoSomthing();
return;


    }

pluses and minus

more listens = bigger code
more listens = less logic in your own code (and less parsing of it)

it's presumable that the sim can handle filtering more effeciently than your script, but if the logic for your listen doesn't get much improvement and you're using a low traffic channel, you're probably better off just having a general listen and not having logic to find and open individual listens

I think the wiki answer cited is a subjective opinion. The answer must depend on the particular situation.

I would expect the transition into LSL to be a lot more expensive than simply checking a few more filters (filters are pretty darn simple logical conditions). I also suspect, since an exact value is required, that channel is the very first thing used to "filter" (or it would be if LL had their act at all together).

Assuming the above are true, you would be better off with multiple filters if they are likely to rule out a large number of chats that you would otherwise have to filter out in your LSL code. So if you are using a channel with heavy traffic (especially channel zero) and you don't expect to process all of that traffic, multiple filters might be a good idea.

If, on the other hand, you pick channel numbers wisely (including randomness if possible/appropriate), and use different channels where possible (e.g. possibly use a common channel to setup communication for a system on a "private" channel), and don't make use of channels that are likely to get a bunch of traffic from other systems (i.e. not zero or low positive channels), the multiple listens aren't likely to buy you much. And if that is the case, code readability and maintainability might be a more important concern than performance.

Hi Guys,

And thanks for clearing that up

I will, (hopefully) be using an obscure channel, generated from a hash of the owner key and object key and being a negative 10 digit number. As an added measure I intend the object to only accept messages from a list of objects who's keys are known to it. Each satellite object will in turn will be listening for a reply on a channel known only to it and the host object. So given your insight I guess I could go either way, as both hold benefits to my script, but neither will unduly impact Simulator performance more than the other.

I believe that is true. Remember there is a maximum on the number of listens you can have registered to a single script also. No idea if you're likely to be near it (I believe it is 64), but it is another one to keep in mind for this sort of thing. Each "filter" counts toward that limit.

Thanks,

I should go nowhere near that limit, the design calls for 5 listens, so I set a conservative estimate at 10. If it needs more than that then it's time to revisit my design. As it is only one listen will stay open, the others are opened long enough to get a reply only. The design is for lag reduction mainly but if it gives some level of security too then that is a bonus.

Just for reference, here is the hierarchy per Kelly Linden on how the simulator handles listens.

"You are pretty close. The actual order of events is:
1. Chat that is said gets added to a history.
2. A script that is running and has a listen event will ask the history
for a chat message during its slice of run time.
3. When the script asks the history for a chat message the checks are
done in this order:
- channel
- self chat (objects can't hear themselves)
- distance/RegionSay
- key
- name
- message
4. If a message is found then a listen event is added to the event queue.

The key/name/message checks only happen at all if those are specified of
course.

So, the most efficient way is llRegionSay on a rarely used channel"

The higher up you are in the list that the simulator checks against your script the better. So in this case if(channel == XX) would be a little more effiecient then checking against a key. But if you are still going to check against the key AND a unique channel then that would be two tests instead of just one.

if(channel == XX || key1 == id)

And that would be more work instead of less.

No matter which way you go, use llRegionSay instead of llSay even if they are only an inch apart . With llRegionSay, the simulator doesn't have to process llVecDist against the 2 positions.

In my experience, having more listens will lag your script. It doesn't actually seem to be that bad for the sim, but as you approach 64 listens, it seems like your script is throttled. For example, I have a channel scanning script where 64 chosen channels are used, and the messages actually come in up to several seconds after they're said, even in no-lag sims, with no extra processing code in the listen. I'm curious if other people experience the same thing.

Don't know, out of curiosity I just tried it like this, but then again, there isn't anything else to process:

chan = 100;
default
{
	state_entry()
	{
		do{
			llListen(chan, "", "", "");
			chan ++;
		}while(chan < 164);
	}
	listen(integer channel, string name, key id, string message)
	{
		llSay(0, message);
	}
}

I typed "/163 Hello, I am working here" and recieved the message back in 1 second looking at my watch.

BTW Cool, I hadn't ever tried adding listens like that and it worked fine.

EDIT: To test it further then I put this in another script and named the object "object 2":

default
{
    state_entry()
    {
            llListen(163, "", "", "");

    }
    listen(integer channel, string name, key id, string message)
    {
        llSay(0, message);
    }
}

"[18:13] Object 2: testing 1, 2 ,3
[18:13] Object: testing 1, 2 ,3"

So the single listen was faster but still no more then about a second. Wouldn't hurt if someone did a direct comparison of two scripts the same way. The first one with a single listen and if test multiple keys and another testing multiple listens.

I brought it to the nth degree. 9 scripts in one object testing from channel 100 to channel 600, 50 listens each, setup like above. Other object with a single listen and then a final object setup with this script:

integer a = 1;
default
{
    state_entry()
    {
        llListen(0, "", "", "");

    }
    listen(integer channel, string name, key id, string message)
    {
        if(a == 1)
        {
            llResetTime();
            a = 2;
        }
        else
        {
            llSay(0,(string)llGetTime());
            a = 1;
        }
    }
}

Tested several times and the consensus went something like this:

"[18:36] Object 2: testing on channel 550
[18:36] Object: testing on channel 550
[18:36] Object: 0.686774
[18:36] Object 2: testing on channel 599
[18:37] Object: testing on channel 599
[18:37] Object: 0.556518"
So a single listen is slightly faster then a large amount of listens. You would stil have to test though whether multiple listens is faster then checking multiple keys.

Except that there may be multiple systems using the same channel in the region. If possible and reasonable, of course, those systems should be configured to use different channels and/or filter by key, but that's not always the case. I highly suspect that processing a message in a LSL script's listen handler is always going to be more expensive than a distance calculation done in the simulator code. So if a distance filter is likely to help rule out processing of messages that the LSL event handler is going to throw out anyway, I think it is still wise to use it.

For matters concerning the backend I would still accept the word of Kelly who is definitely the authority on the subject. Since the time he made the statement I switched over entirely to llRegionSay for prim to prim communication. Distance is one of the lowest common denominators and shouldn't be a deciding factor with 4 billion channels to choose from. Channel/Key gives the same, completely safe results as Distance/Channel/Key and is less expensive. The only time it could ever be considered less so is if chatting prim to prim on a common channel and that is a major no no.

Looks like 6 of one and half dozen of the other. Tested 30 itinerations and came up with results like this:

"[19:30] 1 listen, 7 if test's for keys: Testing channel 599 1 listen w/ if test's against multiple listens for each key
[19:30] 7 listens with different keys: Testing channel 599 1 listen w/ if test's against multiple listens for each key
[19:30] Object: 0.064595
[19:30] 7 listens with different keys: Testing channel 599 1 listen w/ if test's against multiple listens for each key
[19:30] 1 listen, 7 if test's for keys: Testing channel 599 1 listen w/ if test's against multiple listens for each key
[19:30] Object: 0.064525"

Sometimes the single listen/multiple if's was faster and then other times multiple listens keyed for different keys was faster. So whichever way you want to do it.