which is better? 2 specific llListens or 1 all purpose llListen?

Ok my assumption is going to be to use one llListen() and then good if(..) statements in listen() is better that two specific llListen()s.
I am not going to use channel 1 as it is unintuitive to type /1command and I want to avoid IMs from confused newbies for my products.

Ok, people are a bit confused.

By far, you must care about the NUMBER of llListens you use BEFORE you care about what channel they are on.

Yes, a channel 0 listen will be "worse" than a channel 1 listen, but only in the sense of saying Sprite tastes better than 7UP. The difference is infintesimal compared to the difference between having two non-0 listens and only one listen on any channel.

Realize that an opened listen is a CONSTANT drain on server resources, whether someone's talking to it or not. Two opened listens are an even BIGGER constant drain. Channel does not matter.

Moleculor -

I gotta disagree with you on this:

The llListen() causes the sim to parse any chat message on the specified channel. Yes, there is a certain "constant drain" on the system to even be running a "parser", waiting for messages...

But the parsing has to be done on every Message in a Channel. The more messages, the more the listener has to parse. The more the listener is invoked to parse things, the slower the script & sim will run. It may not be "visible" unless there are lots of Av's making lots of noise - but the impact is there, nonetheless. Put 100 scripts all listening on Channel-0 in a pile around some Avatars talking; and performance will go down. As SL gets bigger and population density increases, this will become more of an issue.

If, for the sake of argument, all the Avatars were talking on Channel 1 and all the scripts were listening on Channel 1, you'd see the same slowdown. But since default chat doesn't happen on Channel 1 - the "message traffic" on that channel is much less; and therefore "lightens the load" on any listeners on channel 1.

Psyke -

I contend that its very easy to give your customers a notecard telling them how to use the proper channel (plenty of objects in the game already do this). Its not as easy as them using channel 0... But its pretty damn close; and here's another issue: on channel 0, you're liable to have anyone say anything. So you may get others speaking "commands" to your object on channel-0... either deliberately as a grief, or accidentally in conversation - if you don't plan for this possibility. Regardless of channel, its often useful to filter the source of any "commands" against the current user's UUID / Key.

For example, inside your listen() block:

listen(integer channel, string name, key id, string message)
{
    if( llList2String(parsedMessage, 0) == "my_command" && id == llGetOwner() )
    {
        //Do something in here
    }
}

Or as Hiro pointed out above, use this syntax in your llListen call:

llListen(someChannelNumber, "", llGetOwner(), ""); 

But I agree with Mol that at least you're using only 1 Listener.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

My 2 cents. A lot of my stuff involves voice commands.

I DO use channel 1 for commands (/1command). I do this because I don't want the commands entered into the chat for all to see. If I was in a MUD, I wouldn't see peoples commands, just the results of them. Is it less intuitive? Maybe if you are an idiot. I expect people who can handle reading and writing can also handle /1, and probably appreciate it. I definitely don't want something with my name on it cluttering up the chat, at any rate.

However, that is the for the purpose of command entry. If you need to use channel zero, I say use it. I also say you should always do your best to make your code efficient, but different people are at different skill levels. Scripters in general should probably try to be considerate, but I don't think any new rules need to be implemented.

I agree that on a general listen, there is some impact on the sim. But that burden is there every time an object moves, every time an avatar moves, every time anything that matters happens. There is so much going on that I don't believe that even in a full sim with a bunch of people gabbing that you are going to have much trouble. If you wanna run a ridiculous experiment with 15000 objects with listens and 60 people pasting text, sure, you might have a problem. But that is not the typical in-use scenario, and computers are really fast, even at parsing text.

Yeah, I use a llListenRemove and then redo the listen on_rez.

Which reminds me of something else. You really should use llListen as an integer and llListenRemove before each time you call llListen.

integer storeListen;
llListenRemove(storeListen);
storeListen=llListen(10,"",llGetOwner(),"do it";


Mole,
That "hardly perceptible" open listen may be hardly perceptible to one person, but when you're talking 20 listens listenening to 30 people in a club, it gets insane.

Careful when applying logic to LSL optimization problems. Not all of it makes sense. In order to demonstrate your theory, you should back up your opinion with performance numbers.

Let me give you an example. Way back when I first started programming LSL, I had a script that listened for many commands on a single channel. I decided to break up all possible valid inputs into my script by specifying multiple listen filters.

I reasoned that since the filters were implemented in C, and run natively, they would surely run faster than using interpreted LSL to cull invalid commands. Makes sense, no?

Well, as it turns out, the theory is completely wrong. Chat in SL is (or at least was) implemented as a single sim-wide circular buffer. Each listen filter crawls the entire chat buffer, looking for a match. So, more listen() statements causes each message to be proccessed (whether it be on the same channel, in hearing distance, etc) more times. In the end, it was better to specify a single listen statement, and pattern match in LSL.

Optimization in LSL is a black art. It is full of many counter-intuitive ideas. Personally, I've decided not to listen to anyone claiming that something is laggy/not laggy without seeing experimental results. Anything else is just opinion, and we all make mistakes.

I haven't personally verified that listens on channel 0 should consume more compute cycles than listens on any other channel. The way I understand LSL, it shouldn't make a difference. However, I would be happy to see any experimental results.

Perhaps we can combine our results to come up with a better understanding of LSL optimization.
/54/c8/25865/1.html

I strongly second Francis' post.

-Adam

Francis, thanks for showing us the experiment results.

Francis thx for your insights. Consequently i believe i'm partialy the cause for a portion of gridwise lag. Back when i was a noob living in Darkwood my friend had a linden candle script that had been badly modified and i had the opertunity to reduce it's two listen's to one but i didn't take it. This candle script is now *everywhere*.

Francis -

Its not that channel 0 itself takes more compute cycles. Its that the buffer in channel 0 is being filled more often, because its the default chat channel. So the buffer has to be checked and processed more often - and that is what causes listens on channel 0 to be more of a drain than listens on other channels.

There are many quirks to LSL - but the fact is that every string sent out on a chat channel must be examined by every listener on that channel. More chat = more checking. And channel 0 has more chat messages than any other, because its the one Avatars use to converse on.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Well, OK then. I'm glad at least someone was thinking like I was. Guess I was wrong

Tread,

Let me rephrase. I'll try using this bold tag that seems to be all the rage these days.

There is no "channel 0" buffer. There is one chat buffer for all chat. Every string sent out on a chat channel must be examined by every listener on every channel.

By performing experiments, you can avoid falling into these counter-intuitive pitfalls.

*Disclaimer: This at least used to be true circa 1.4. I haven't verified that this is still true.

Yeah Fran, it's still true.

Tread, the reason llListen is laggy is because it is a constant 'pull' operation, the size of the so-called 'buffer' is irrelevent, it's the fact that it's being constantly 'pulled' that is causing the problem.

-Adam

If this is true, it's more than sloppy programming!
I think at least channel 0/other channel buffers should be split up, moreover, it would be better to have an "index table" with maybe (dynamic) chains of listening objects for a channel.

I think of something like this:
1. Chat on channel 2003 started (by object or avatar)
2. Search for channel #2003 in listening channel list (if none found, processing ends)
3. Go through the chain of channel #2003 listener objects, check distance, activate each one that's close enough. Filtering rules can be processed in the "runtime" level, no need to activate an object if it listens to only another message.

(Of course, this is much more complex because of scheduling/time slices, but it could be a basis.)

Maybe it IS coded like this, but if it is, there shouldn't be much (just a bit) overhead because of a non-0 listeners.

I heard a lot of 'if's 'maybe's and 'but's.

Apply scientific method: formulate a theory, design an experiment that (dis/)proves the theory, design a control experiment, run the experiment, analyse the data and formulate a summary.

Or ask a Linden how it really works.

Maybe it can be enhanced? Maybe it's not broken.

Ultimately establish the actual case and then hand out the advice on how best not to waste the simulator.

Does this mean: 'Work hours for Linden Labs -- for free'?

I was seriously under the impression that the different chat channels had their own buffers.

If they are all on the same buffer and non-0-channels are simply "hidden", then I agree with you guys on the lag effects that would have. I still say that - due to the possible mis-interpretations from excess chatter - it's still better to listen on another channel. But you're right that knowing how it works would certainly provide more definitive answers...

I recently interviewed at LL; and if this thread had been going on, I would've asked a Linden... dangit! If I get in, I'll be sure to find out and report back!

Take care,

--Noel "HB" Wade
(Tread Whiplash)

I've forked a thread on a related topic, avoiding listen lag by touch activation of listens.

/54/4e/34641/1.html

Where do you get this from?

I believe Cory, or Phoenix, way in the past, made it pretty clear that more listens is bad, and the more they have to process, the worse it is. However, considering the lack of performance of link messages, listens are really the only way to pass around data FAST. My practice is to rez them when I need them, leave them as long as I need them, discard them as soon as possible (for instance, if you want to remove a listen for a particular command).

Keep in mind that a state change for ownership guarantees (insofar as things are guaranteed in LSL) that your listeners (and whatever else) are removed and your events cleared. If I recall this does not apply to timers. I've found this to solve a number of coding problems related to ownership and such in the past (my default state is typically an initializer of global values, and passes to one of two other generic states each with more specific initialization code, Working and Waiting or whatever). Keeps things factored, tidy and ensures cleanup of things that may not otherwise be used.

That is if anybody still uses states anymore I love 'em.

Tcoz -

Okay, now I'm going to be the one asking for facts to back that up....

I have not had any noticeable lag in my llMessageLinked() calls. They have been as fast, or faster, than my llWhisper() and llSay() calls.

My current project uses 6 different scripts all on one Prim - and linked-messages have proven fast and reliable.

There is no way to instantaneously transmit data between scripts in LSL... But I have to question your assertion that llMessageLinked() is somehow slower.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Okay, did my own test:

Two scripts on 2 box prims next to each other.

In the test, I set up 1 script to respond to any "ping" Whisper with a "pong" whisper. The other script replied to each "pong" with a "ping" - so I had a circular message queue going on. I set a loop limit of 100 messages in each direction, and ran it. According to a timer set up via llGetTimeOfDay() calls, it took 19.6 seconds to implement this. This figure was obtained by running the script 3 times and averaging the results.

I then used llMessageLinked() to do the same 100-iteration test on 2 scripts on two box prims linked together. The total elapsed time was 12.03 seconds (again, averaged across 3 runs of the script).

So there is a nearly 40% improvement by using llMessageLinked().

Test conditions were a relatively fast Island sim with about 20 Avatars at the extreme opposite corner of the sim from my test.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

In any decent assembly language reference manual it will let you know how long each command takes to execute.

Do you think it would be possible to document all the timings of LSL functions in the wiki?

they are documented in the wiki script delay




jester

I can show you, extensively, that listen messages are slower. I have been through this in great detail.

Try this...expand your test. And don't use channel 0.

Try sending FIVE, or better yet, FIFTY, listen messages to ONE object from the SAME object Then send FIVE/Fifty says to ONE object. Do them in a loop. No pause.

Set up your trace(say msg) in the link message event for link test, and in listen for the listens.

See which one finishes first.

I have overwhelmingly and with many, many examples, concluded that linkmessages can not be used for rapid real time updating of information. For example, if you have a observer of some kind that notifies another object of rapid bullet hit, say you get hit with a burst of five bullets very rapidly) The link message technique will be very slow. The listens work instantly. I restructured the entire architecure of my mHUDS for this reason, and now my damage processing is about as fast as SL can make it. Almost nothing gets queued (or rather it doesn't stay there for more than a blink of an eye).

Sure, one link message, yah maybe. But do something serious that depends on link messages as its core mechanism for hundreds of real time updates, and you'll see my point right away. In fact I even used the example to open up the whole "clearing events on state change" can of worms a few releases back (I proved that events were not clearing because link messages would suspend, not clear, on state change). I discovered it from standing around waiting for link messages to my damage meters to finish processing.

Your test is valid in a very limited scope...send and respond. But I want to send 50, or 500, or whatever, fast, now...we ain't building web pages here. Recently one of the Lindens pulled me off to the side to ask about my experiences with games dev in SL. This was my number one complaint (other than ghosting ARGH, but I think I solved that one, or at least know how to solve it if I have to). I don't like the idea of "listeners" being active all over, but it's the only way I can get an SL FPS to click along at the speed it needs to. \

Come check out the Vorago and my mHUDs sometime if you want to see this all in practice. I might even be able to dig up an old one to show you the difference.

Take care.

I guess I should also say that if they improved link messages dramatically (and I mean dramatically) in the past release or two, I didn't see the note and will run my tests again. But I doubt it.