Optimizing scripts based on sim performance

Sims have many events that need to be executed within an ~22ms time window in order for the sim frame rate to remain reasonable (>40FPS). Sim performance can be monitored in a script by using llGetRegionFPS, llGetRegionTimeDilation and llGetRegionAgentCount (please post if you know of others). Sims with over 50 avatars, FPS of < 40 or a Time Dilation of < .90 show the sim is starting to have performance issues. FPS of < 20 or a Time Dilation of < 0.50 show a sim has slowed down to the point of lag. Scripts are the last to be executed during the 22ms time window making them the first to suffer from sim performance. I have monitored a number of laggy sims to try to get an idea of when the sim is near a lag condition. One thing that stands out is a sim can drop to lag conditions in one frame and bounce back to optimal conditions in the next frame. But what about the numbers between optimal sim performance and serious sim lag?
I have looked through the forums for information about sim stats on laggy sims and found very little information. Knowing when a sim is near lag conditions would be helpful to scripters so they can designed the script to adjust itself by reducing or turning off certain calls that would slow the sim down. In a scanner/radar script adjusting how often llSensor is called, the distance llSensor is set to scan and the number of objects the scanner is set to detect can all help with the sim performance, but these is just some ways of improving the script's performance. Has anyone looked at other ways of dealing with sim lag in a script?

I'm not convinced that this is something we-as-scripters should worry about. Imagine how much load a thousand scripts, all looking at how happy the sim is doing, will add to the sim...

Better to let LL deal with it in their scheduling code and just try to do your best to write efficient scripts.

Most scripters, from my experience, don't actually know how to reduce lag, and instead overemphasize the idea of optimizing listen, timer, and sensor use (which, while potentially a problem on a large-scale cumulative basis, generally aren't as bad as they're made out to be). The biggest problems for sim performance, in my experience, are physics collisions and (looped) abuse of high-impact functions, or just infinite C loops in general (each is like .1ms or more, which is a relatively large contribution for one script).

I very rarely run into areas where -scripts- are causing lag. Usually it's oversized textures, gigantically complex prim-builds, and overloaded avatars (render-cost 3000 guns anyone?).

Optimizing scripts is always good - and I will continue to do everything I can to ensure that every one of my scripts never processes anything unnecessarily ... but lag culprits are usually not scripts.

These are things that precisely do not cause the aforementioned 'lag,' so it might be good to spell out the definition of the word. Lag in the sense being used in this thread so far is sim slowdown, or time dilation. The things you just described are all problems that affect the client's framerate, not necessarily the sim (although the constant loading and unloading of all these things, particularly during agent teleports, can cause sim lag - check out Armidi, it's like molasses).

My personal list of the top three things to avoid where you can:

- Physics
- Listens on channel 0
- Large numbers of timed events (esp. sensor repeat)

It's unfortunate that all three are the most likely kinds of functions you will use when you first get into LSL ("noob lag".

Generally it's a good idea to use estate tools/debug top scripts and isolate & kill off the few "rogue scripts" that are hogging sim resources. Killing off "bad" scripts will generally sort out 90% of the lag issues caused by scripts (there are MANY other sources, as Tyken pointed out).

Beyond this script optimization is generally a case of hugely diminishing returns, as your applications will become unmaintainable if you take it too far and make them unreadable.

/esc

Coda:

Any sim running at 0.9 time dilation or less is noticeably less responsive.

Sims appear to cap total script time at around 12ms -- so further increases don't "show up" except that everything works slow.

If you own a sim try to keep your script time below 9ms and your time dilation running at 1.0 for at least 70% time.

/esc

/me has yet to spend any amount of time on a region with greater than 6ms script time - most are around 3-4 ms. Maybe I just hang out in regions that know how to use scripts responsibly? I can't even imagine a place with 9, 10, or even 12 ms script-time.

hey!

ive noticed, physics on ground can increase the lag and a server doesnt run rocksolid in framerates -> statisticsbar open

my sim runs mostly healthy
total frametime 0.4 ms
scripttime 0.3ms
net time, physics, sim time other, agent time, images time -> 0.0 ms

- sometimes the total frame time increases to 0.9 - 1.2 ms without any reason - maybe for 1 second.
- in some rare case (1-4 times a day) the frametime increases to 22xx.0 ms without any reason. in this case net time increases to the same amount (22xx.0 ms) - maybe for 1/2 - 1 second.

monitoring 24/7 - > 1 full sim, one person, 6 groups and ~20 friends on list

Does anyone have an idea how object updates are in terms of sim load? That is, moving (non-physical), changing textures, etc.

They definitely contribute. The worst are the smooth non-physical movement scripts that update object position like every 0.05 seconds by using multiple concurrently running scripts to stagger operations and compensate for the script delay imposed by the functions. Use those very sparingly.

Some updates, stuff like position or rotation changes, just send out a partial update - these are pretty cheap though you could probably still hurt a sim by doing tons of them frequently. Physical movement is in this category.

Other updates, changing prim properties or hover text or stuff like that, send out a full object update. These aren't as cheap but their expense really depends on how complex the object is: doing full updates on a single prim probably isn't a very big deal. Doing full updates on a 255-prim object is a different story...

A number of the posts in this thread identify causes of sim lag which is very informative. How do you deal with the lag in a script? Let's take a common problem I see with many of the scanners/radars I have tried. In a well behaved sim you get quick and current information on objects within llSensor range. Now take the scanner into a laggy sim and the scanner just about locks up. Not only is the scanned objects information no longer current, but it can also come at random times. A scanner script in a laggy sim is just about useless from my observations. Can a scanner script be written that can give information at regular intervals and be current in a laggy sim?

Nope!
While in SL hit these keys (ctrl,shift,1) which will bring up the statistics bar. Expand Advanced and expand Time(ms) at the bottom.

A simulator only has 25 ms Total Frame Time to be divided up between everything;

Sim Time
Agent Time
Images Time
Net TIme
Physics Detail
etc and finally
Script Time

Script Time is the sacrificial lamb in the mix. It is the first thing cut when anything or a combination of everything else uses that 25 ms.

I have a feeling that much avatar attachment/general script lag could be eradicated by having to get a license to use the single function: llSensorRepeat().

/esc