Scripts, images & lag

I've attempted to read up on the causes of lag in a sim. I can understand the problems caused by a lot of av's, incorrectly created textures (big is slow to rez, small is quicker) and the users own pc/connection, but one thing still has me baffled - scripts. What effect do these have on the overall performance of a sim?

On my home sim, there are 5,100 active scripts & script performance is approx 20,000 ips. I occasionally have rezzing problems, but not many. On another sim, very slow to rez, there are 3,700 active scripts & script performance ranges between 30,000 - 60,000 ips.

What sort of effect is the low number of active scripts with high ips going to cause in a sim?

A really, really simple answer would be nice.

From what I understand of scripts it basically comes down to listens and redundancy.

If you have a lot of active listens on the same channel (/0 especially) then that's gonna slow you down more than having few listens or things that only listen to certain objects/avatars as opposed to whole chat channels.

Your sim with many scripts could be full of good scripts made by people that were keeping lag in mind. The sim with few scripts that's lagging could be full of freebie scripts or otherwise listen-heavy scripting.

As far as redundancy...basically the less lines in the script the less the system has to deal with and translate into actions/effects/whatever.

I know there's more to it than that but those are the two big things i've noticed in my travels.

I heard it can also be caused by having older computer i.e not enough ram, slower processor, video cards and low speed cable or dsl connection with too high graphic settings. Is this true?

I read somewhere that the time allocated to script slices is limited so that it does not interfere with the other sim activities. So script lag would only affect other scripts.

Feel free to contradict me if you have better information.

A script itself does not necessarily produce lag. Take a poseball script for example (without timers or listeners). The sim server has no work with it until someone uses the poseball. Only when someone sits down on the prim, the server checks the scripts inside the prim for handlers dealing with the event of someone sitting on the prim and executes the corresponding code. The rest of the time, the script is idle and uses no CPU resources.

There are script functions though that keep a script busy all the time (timers). Or whenever a resident is near (sensors). Or whenever chat is overheard by the script (listeners). A single script using a sensor with maximum range, a fast timer intervall of less than 1 second and several listeners will create more lag than 50 poseball scripts.

Well, the scripts usually do something while they run. They send chat messages, communicate with other scripts on invisible chat channels, request environmental data like scanning for nearby avatars, move prims... all that adds overall sim lag.

It would be nice if there were that simple answer.

If you look at the statistics bar and watch the graphs in a moderately busy sim, you'll see that script time gets the time "left over" from everything else. But, of course, scripts can *cause* everything else, too. So, if a sim is in time dilation due to physics, for example, probably there are scripts in the sim doing physics (or a whole lotta avatars clomping around in those big heavy boots ).

One thing that may be surprising is that *any* script in the running state consumes some modest amount of CPU, even if it has no active event handlers. An example is the ever-popular texture animation scripts to make prim water look like water. They do absolutely nothing after they execute once in the prim (the texture animation becomes a property of the prim and is handled client-side)--yet their very existence consumes some sim script time--but not very much. (They can be removed or set not running and texture will still be animated. Same with constant particle scripts, rotation using llTargetOmega(), simple sit targets, etc.)

But it's very rare that lag is caused by scripts doing pure computational stuff (accessing memory, doing math, sending and processing link messages, etc.)--but this will certainly elevate ips, as long the sim isn't too busy doing other stuff.

Now, as if that weren't confusing enough, the OP refers to rezzing delay as a criterion for sim performance, but (especially lately) that's most often due to bottlenecks in accessing shared resources, not lag in the sim itself. If the sim is in time dilation, then yes, rezzing will be slower, but when the overall grid is very busy, even a completely idle sim will have trouble rezzing.

Well ALL scripts take cpu time.

Some more than others but as far as I've been able to determine the majority of scripts are really doing nothing. Dead scripts that set a prim property like an animated texture that are never run or messaged again. And ther are SO MANY of them that they actually take up more sim time than the much smaller number of highload scripts you may have running.

In a sim with 3000 scripts as many as 1500 could be shut off as they are not really doing anything. And that makes a HUGE difference.

Yes, scripts each get throttled when the sim runs out of cpu, the run slower and slower the more therre are. After a while this reusts in poor efects for anything using scripts but it also does cause HUG lag spikes in the sim.

When something happens in the sim that requires CPU that is NOT script related well, it doesn;t esist! THe script interpreter is using it all and it take time to react to slow down. So yeah I notice that the more scripts there are the more frequent and the deeper the big spikes of lag.

I and my friends generally keep would sims down to 300-1000 scripts and they run like a dream, EVERYONE says they are the fastest palces they''ve ever been in sl. Keeping the number of scripts BELOW the throttling threshold is a great goal to keep your sim humming along (Till 5 800 script dragons show up)

In my experience a class 4 sim can handle 1500 scripts of an average distribution of complexity before Permanent time dilation and script throttling. Class 5 is about 3000. (these are sim scripts plus every script on every av in the sim of course)

I tried to get rid of the scripts that only set a prim property and are no longer needed afterwards. But then my moat froze over and my ducks died each time the sim crashed (meaning, the water animation + sound stopped and the ducks stopped rotating). Texture animation, particle effects, prim rotation using llTargetOmega or sound started with llLoopSound need no permanent script, in theory, but after a crash those properties might be lost if the script is missing.

Scripts don't cause display lag or physics lag. That is, they don't slow down the frame rate, or make your movement lag when you try to walk.

Scripts CAN cause other scripts to lag. I call this "script lag". For example, this would cause it to take a long time between sitting on a poseball and the animation starting. Poseballs, danceballs, sploders, vehicles, animatronic pets, weapons, and doors are all scripted objects and are affected.

I have a suspicion that script lag can also cause chat to lag, but I haven't ever tested that. It wouldn't be hard to test, in a relatively empty sim. If it's the case, I hope that it would be limited to "too many open listens" rather than script lag in general causing it. (Yet another testable hypothesis.)

I suspect that script lag does not cause IM lag, because I've seen cases where the chat lag was very high (as was script lag), but IMs were prompt. But anecdotal evidence like that can be misleading.

There's another good thread on scripting to avoid script lag. Let me know if you have trouble finding it by searching and I'll see if I can find it. I know I posted on it, which might help to find it.

Right, Aleister. So, it's better to simply turn off the script and leave it in the object. That way you can turn it on after a crash. Note that this isn't much of an additional burden, because even if you left the script in and running and the crash caused a problem, you'd still have to visit each duck and restart the script (which usually only does something on startup of the default state, which does NOT happen after a sim crash or we'd have SERIOUS trouble).

If you've never had to visit each duck and restart the script, then you haven't seen this problem when the scripts were left in.

A sim restart usually triggers the on_rez event, where I put an llResetScript or just repeat the texture rotation or whatever the object needs. You're right, it wouldn't be much work to manually reset the scripts, but I'm lazy

One might also note that the scripts listed in the aforementioned stats include the ones that avatars are wearing within the sim. I think its an often neglected bit of knowledge that the huds we choose to wear and other scripted goodies can effect the sims we are in greatly.

I once wore a HUD and entered an empty sim, as in just landed, unterraformed, nothing but myself and two other people in it and one of the other two noted an extreme change in the scripting performance for the sim. We had to disable all my scripted attachments and re-enable one by one to find the sim killer.

I have watched sims as estate manager/owner that were perfectly fine one moment have one additional visitor that suddenly sent scripting spiking, and often the additional lag was something that could be noticed immediately.

How do you know if you're a walking sim killer? Count the prims you're wearing (a thousand prim necklace is gorgeous detail, but its really hard on sims.... one more reason events are so laggy), go to any sim and strip off all your huds and scripted attachments (this includes things like color change shoes or hair) and watch the stats as you add back your goodies. It might surprise you simply watching the *number* of scripts change, but hopefully the scripting *time* won't be highly effect.

Note that many scripts in huds will only effect the time when actually in use and are otherwise dormant, using minimal time at best. The killer hud I was wearing had an active sensor in it that was at regular intervals checking SL at large for information. I haven't worn it since.

Cheers!
Char

Interesting that a sim restart causes an on-rez. I don't think I've ever seen this, actually. Frankly, I think it could cause some grief with certain scripts, so thanks for pointing it out.

BTW, I have a fire whose texture animation script is long gone and it still works. Perhaps my sim never crashed such that it had to be restarted that particular way? In any case this is a rare event (or certainly should be!)

If it's true that restarts after sim crashes always invoke the on-rez, we could implement a simple sim crash counter!

llTargetOmega requires the script t continue to be active yes.

However, I've had my sims crash dozens of times and never had a prim property set by script revert (i.e. sound loop, animated texture, sit target, phantom or anything else that is a true prim property (some plants sell with a running "set phantom" script in them ugh!)).

These are properties of the prim, they are just not available in the edit window but could be. Once set and once they get into the temp and permanent backups for the sim they really can't revert under any normal circumstance, including sim crashing. If they did then all textures, prims and everything would randomly be reverting all the time

There MAY be some scripts that change the speed of the water texture in a moat for example or somthing more complex or something, in some rare cases leaving such a script running is necessary, but I was able to remove 800 of my original 1600 scripts from my sim like nearly a year ago and have not had to restart any of them ever.

Thanks to everyone for their responses.

The sim we're having problems in, has quite a few houses, a very large swimming pool with pose balls, showers etc. But, I've since noticed that a hot air balloon and small train located there, both merrily move around regardless of anyone using them.

I'll get my friend who lives & works in the affected sim, to nicely ask the owners to temporarily remove a few items (balloon and train, in particular) and see if thing improve.

If it's a private sim, ask the sim owner to find out which scripts are using the most CPU time. Too bad we can't all do that!