Lag in scripts

What are some rules of thumb I can use when programming in LSL to reduce lag? (i.e. what causes a laggy script?)

Here are a few things I like to avoid:

1. Listening to everyone on public chat channels. Listeners in general cause lag.
   
2. Things that trigger very quickly, and often. (ie: Checking for e-mail every 0.1 seconds, or triggering a 96m sensor every second.)
   

I can't think of anything else off of the top of my head.. lol There are a lot of things that are better to avoid, or seek alternatives.

Essentially, every time the script does something or causes something to be done on it's behalf, the sim spends a few cycles doing that thing.

Assume the sim works in a unit of time called 'ticks'. The sim can handle X ticks worth of stuff per second. Doing a sensor sweep, say, might cost 150 ticks plus 10 ticks per detected thing. An inventory transfer might cost 100 ticks. Rezzing an object might cost 30 ticks.

When the server runs out of ticks to spend on doing stuff, performance begins to suffer. Ticks are a shared resource for every object, agent, avatar and script in the sim.

The trick, essentially, is to figure out the smallest amount of work to achieve your goal. Unfortunately, there are a couple hazy things. We don't really know how many ticks per second a sim can service (and the number varies a little anyway) and we don't know how many ticks various operations cost (though some people have done some fine work on figuring out *relative* costs).

If you are using listens, for example, on channel 0, then every time someone says something where your script can hear it, a few ticks get used to see if it passes your filters. If it does, then more ticks get eaten up by your code in the listen event.

Likewise, every sensor scan uses ticks too, for the scan, and of course for your script processing the results. If you keep the rate of scans down to the slowest rate you can practically get away with, then your overall tick-usage won't hurt things very much.

LSL is generally oriented around events. Your script should probably spend 99% of it's time asleep, waiting for one of it's events (touch, money, sensor, timer, listen, etc) to be triggered, do the minimum amount of work and be done.

If you've got a LOT of work to do in a script (lots and lots of code to perform actively on an event) but small delays won't hurt, think about using llSleep() to introduce small delays into the code...because sometimes it doesn't matter if the job is done in 1 second or 10 seconds, so long as it's done.

Did I just make any sense there?

You always do, Tat
Jef, it's impossible to answer the question completely because there are just sooo many different things and combinations of things that can cause lag (in its different forms).

Stylez and Tateru have highlighted the biggies. To learn more I would recommend lurking the scripting forums regularly, you will often see efficiency discussions on concrete pieces of code. Also upload snippets and ask for comments, so that we can discuss specific issues - you'll very quickly pick up a feel for what to avoid.

The most important thing of all is actually giving a s**t and being willing to do something about it (even if it's a bit more work). Creating this thread shows you've got that - keep it up.

giant if loops and physics