Active and Passive Scripts

I want to know the things that make a script take up sim resources, or become active, and how much of those resources they take up. I try to keep lag to the lowest possible amount in my scripts, and that's why I'm asking.

Here's what I know:
listens, sensors/sensorrepeats, and physical objects take up sim resources, however, I do not know how much each takes up. I use listens whenever possible instead of sensors, because I got the impression that they are less laggy, but I don't know if this is true.

What I want to know: do any other functions/events cause noticable lag? Timers? Collisions?Emails, GetEmails?...?

I think it would be good to have a list of all this so that new scripters can see it, avoiding the temptation to make those candles that go on and off it someone walks within 20 meters of them from a .1 second sensorrepeat

Implementing any event handler in a script adds a bit to the general lag, so even truly passive objects can still contribute lag.

Now, some events are more laggy by nature: a listen implies that the server will filter all chat that goes on in the sim and neighbouring sims, look up AVs and listening objects in the vicinity, and relay the chat to these according to whatever filter you have set up the listen handler with. That's a lot of work, so having a listener in an object contributes more lag than having a collision handler (as long are both are unused).

A collision handler in a standing object is only called whenever something else bumps into it, so that doesn't contribute much lag at all simply by being in your script. I believe the at_target events work the same way. Touch handlers are probably just as cheap on sim resources, if not more.

A control event also is only called whenver the AV whose controls are taken presses or releases specific keys, so the existence of the handler itself doesn't contribute much lag. But it tends to be called a lot, and faster than most other events. I think it's on par with timer handlers here.

A sensor works in a more generalized way than a listen, one call uses up more sim resources than a single chat line, of course, but I truly don't know how much more. The sim has to check objects and AVs in the vicinity and record information about all these then send it back to the script, that's a lot of effort (= more lag).

So if you want a (very!) rough ladder of Lag-Inducement for handlers:
1) sensor
2) chat / listen
3) control
4) timer
5) collision
6) touch

Can you consider making your candles only go on/off when touched ? If they absolutely have to switch on/off according to presence inside a given area, then I suggest going with a collision handler and a VolumeDetect prim to cover the area. This way the code only gets triggered when someone trips into it. If your candles are standing still the sim does not have to check its collisions continuously, greatly saving on resources. It'll only have to check them on things that are already moving anyway, so you're hardly contributing any lag with this method.

Disclaimer: I have not tested experimentally any of the affirmations above But these are the "rules" I try to follow when coding.

Things that force complete or partial prim updates chew resources a bit too, presumably complete ones more than partial ones. From memory that's: llSetTexture, llSetAlpha, llSetPrimitiveParams and some others.

The problem with 'how much' isn't that clear cut. A listener in an empty sim has some impact, a listener on channel 0 in a crowded sim undoubtedly has more because it's doing lots more work.

Sensor repeat on 0.5 ought to do twice as much damage as one on 1.0, and one on 30 much less (60 times on average you'd hope), but I'm not sure it's that directly quantified. The other thing is that the sim performance numbers aren't directly related to performance.

Don't believe me, log in find and empty island and tp to it. Stand still, let everything settle as much as it will. Then turn around and you can see your performance (fps) drop, but also sim performance will also often change just from you spinning round and round on the spot - it's doing more work. How does that relate to the impact from a fast sensor repeat...

Thanks guys, and Jesrad, the candles were something I saw somewhere, they certainly weren't mine . Do you know about llEmail and the email event and llGetNextEmail? Is the reason there is a 20 sec delay because it uses a lot of resources? And what about timers, do they do anything?

llEmail has the 20 second delay so you can't generate spam (course you can get around this limitation, and everybody does).

Maybe enabling debaug, ctrl-alt-D, and then enabling 'show update', ctrl-alt-shift-U, can help illustrate the impact of scripts. Does anyone know what each particle color represents? There's blue, red and green.

Green is deletion, blue is a partial update (the sim sends your client just the info that changed about the prim), and red is a full update (the whole prim and all its settings is sent). Of course the faster and the more info is sent, the more the sim lags because of all the bandwidth and CPU and RAM used.

If I have a low baud dial up modem and an 8 MB graphics card, 64 MB RAM and a 550MHZ processor (let's pretend I can still play SL), I would expect lag.

If I have a T1 or T3 connection, a 512 MB top-o-the-line AGP graphics card, 1 GB RAM, and dual AMD64 2.5 GHz chips... essentially enough of a machine to easily accept the data and render it without my noticing any jumps, then there should be no lag.

However, with SL, that is not the case. I could sit right down in Linden Labs at one of the servers and I would see lag. I'm not trying to downgrade SL or LLabs, but I think it's high time they start pumping out some seriously high performance servers. If I have the money and desire I should be able to beef my machine (and internet connection) up to the point where I see virtually no lag in any location on the grid, EDIT: even with 2,000 sensor saturated candlesticks.

We need to push for this so the truly great content creators are no longer limited by the service provider and have to sit and say "well, I could have made a kickass-balls-to-the-wall fully featured game with fully animated /sprites, dragons, referees, whirlywhizzles/, but the best SL can support is this giant rubik's cube, but don't try using it while your AV has clothes on cuz I'm not sure what that will do the server."

It may sound like I'm being hard on Linden Labs, but only because I would really love to see what these guys (the content geniuses) could do unimpinged. Let it fall on the residents to get their client machines beefed up to handle the improved throughput, not on the developers to tone down their creations so as not to burden the server. If the software has outgrown the hardware, get some new hardware and repeat if needed.

</rant>