Script performance and how it works...

I got a couple questions regarding script performance vs. lag.

You read everywhere that open llListens cause lag. How does a listen event differ from a touch event or any other? They don't all scan for the event to happen the same way at the same frequency? If not, how is a listen different? Does it test all chat (including local) to see if the message is on the required channel? I could see how that would cause a little extra processing but its not like us humans can type fast enough to make much difference.

Second question: Take a blinking light for example...no matter how fast you blink it, it can not be using more than .2ms at a time can it? So the problem isn't in the type of script you create, but how quickly you cause the .2ms delay change to happen is it not? Everyone has this idea that blinking things cause lag. It would seem that this would be true only if it blinks too quickly.

Third question: Estate owners get these script scanners. What do the readings mean exactly?

Thanks for clearing these questions up for me. If we can better understand whats going on we can make better scripts.

They don't scan *at all*. That is, the script isn't doing any scanning for chat.

When certain events happen in the simulator software, all the scripts in the sim are scanned to see if the event refers to them.

To simplify: when you say "hello", all the scripts in the sim are checked to see if they have a listener on channel 0. Then the ones that do are checked to see if they're in 20m of you. Then they're checked to see if there's an agent or string filter on the script. THEN the event is called.

The "delay" has nothing to do with how much time the script is using. If your script is on a timer that's blinking it on and off every 0.5 seconds, that means that your script is using a little bit of time on the sim, twice a second. It also means it's sending an object-update event to every avatar in the sim, twice a second. If there are 100 blinking lights, that means it's handling 200 scripts for a fraction of a millisecond each, and sending 200 times the number of avatars in draw distance 'object update" packets over the net.

On the other hand if you implement the blinking light using llSetTextureAnim or llParticleSystem, then that texture is downloaded to the avatar when it comes into draw distance, and from then on the blinking is handled by the client. No lag on the sim or network at all, even if there's hundreds of them on the sim.

Then regardless if a script has a listen or not, it is checked. In this case what is it that makes the open listen a bad thing?

Point of confusion: You said (regarding the blinking light) that it sends an "object-update event to every avatar in the sim" but then said it sends it to the "avatars in draw distance". This is two different things?


While I realize it is always best to be conservative when possible it isn't very interesting to be in a place where everything is static either and there shouldn't be a problem using these things within reason if I understand right. That's a much better answer then to just condemn the use entirely. A sim with 12 shops, each with a blinking sign is pretty trivial as is a dozen open listens unless it has fairly heavy traffic within range of all of them if I understand correctly.

I really appreciate the info Argent. I wish I could find a good text on these things to read.

Sorry, it's the scripts with open listens that are checked.

The second is correct.

Yes, but you can implement those blinking lights efficiently and you can implement them inefficiently. Use animated textures or particles, don't turn the light on and off.