When I first started learning to write scripts for Second Life I heard how bad LISTEN was for performance. In last Monday’s Scripting UG I learned that a llListen() is not as bad as I was previously told. That will certainly change how I script. If you are curious about how LISTEN affects your scripts, read on.
Everything in SL seems to be keyed to frames. The meaning of fames in SL basically the images rendered to the viewer. We see that in the Viewer Statistics (Ctrl-Shift-1) as both viewer FPS and server FPS. Both the viewer and server take a fragment of time and do all the calculations to figure out where everything is and draw the picture we see on the screen.
The servers run at 45 FPS, unless they over load and start to slow down. Your viewer runs at whatever it runs. Ideally your viewer runs at 45 FPS. It been some time since I’ve seen my viewer run that fast. But, 45 FPS gives the server and viewer 22.2 milli-seconds to figure out where everything is and draw it.
Scripts and Frames
Scripts have script time. If I remember correctly, scripts have a 22ms window in which to run. All the events in the script trigger and are handled within that frame. This means for each frame a llListen() will fire. So, it is logical to figure a llListen() will create some load in every frame and that load will reoccur 45 times per second. That certainly sounds busy.
Kelly Linden said, “If your script listens on channel 123 and there is no chat on channel 123 then before your script runs there is a single check against a single integer which will return 0 and nothing more will happen. As a matter of scale for everything else required [, like] to start a script running and what a script does [comparatively,] a check of an integer is no work at all. It (the script system) does a lot of checks before running a script. In this case it may be checking an integer – the pending message count – but it isn’t more than a couple clock cycles.”
Processors operate in the gigahertz range, generally around 3 ghz. That means something 67,000,000 things can happen per frame, provided my math is right. The 2 or 3 CPU tics needed for a listen is 0.0000045% of the available time. (The math wasn’t. I spaced the mhz vs ghz. Thanks Orlando Frequency)
Every CPU cycle used up is a used cycle that can’t do something else. They are not to be wasted. Used wisely llListen() is no worse than any other LSL function.
Only when LISTEN events fire are there additional significant loads. Listening on channel ZERO, local chat, is likely to generate some load. Combat HUD’s that listen on a common channel are likely to create some load. But, it is not the LISTEN event itself that is creating so much script load. It is what the scripter is doing within the LISTEN event that is creating the most.
Efficiency comes by using a quite channel to avoid running the LISTEN filter as much as possible. There are 2 million positive channels and another 2 million negative channels. Finding a quite channel is not hard.
One can kill the llListen() to stop listening while processing the event. One also needs to consider how long it will take to process the event, meaning how long your commands will take to complete. Can it complete in less than 22 ms?
I’m not sure what the cost is to start and stop a llListen(). Some where there is a breakeven point and one needs to know which side of breakeven they are on.
Before the script ever runs a check is made of the channels with chat. Chat in a channel is then checked for distance. Next a key then a name, and finally the message is checked. If the chat makes it thorough all the filter tests then a LISTEN event is set. All this happens before your script runs.
You have the option to set or not the key, name, and message filters. Omitting them reduces the testing on the server side, if I have that side thing right.
Hopefully I’ve made the llListen() less of a lag bugaboo for you than it has been for me.