The FACTS About Script Lag

After scouring over Firestorms Q & A sections, I came across one very interesting respond by one of the developers. They stated the following:

Scripts won’t actually affect your viewer FPS at all. They won’t even affect the sim FPS. Scripts will just “lag” other scripts.

The effects of scripts could cause viewer side lag though, for example scripts spitting out a high number of particles or causing massive object updates (more network lag really for object updates).

The biggest culprets for viewer side lag (low viewer FPS) are rezzed or worn mesh that’s high poly count & overuse of 1024 textures – unoptimized content basically.

Oh wait! So, all this time folks being told to reduce their script counts, and scripts are culprits for lag is not true?

Digging into Second Life WIKI:

Server Side Lag

The Linden Lab servers have to both keep track of everything happening in a map region, and send that information to all the users who can see the region. If they have too much to do, they will slow down the simulator frame rate so as to not lose data. If too much communication is required to fetch data about objects and send them to all the users, it can become backlogged. Since lag can have multiple causes, the Statistics floating window can tell you when it is server-side lag that is the cause.

Things that make the server busier include:

There are many physical (physics-enabled) objects in the region
More users in or can see the region, since it has to send data to everyone who is
More object-embedded software scripts running in the region
Lots of changing textures

So, all the HYPE about to many Scripts, is it true? Does scripts really LAG a sim?

According a Second Life WIKI:

Scripts have the lowest priority for server processing so, effectively, they can only lag other scripts – WHILE processing. The highest priority and therefore lag-impact is handling avatars so you’d expect a busy place to be more laggy. After that is physics – lots of balls bouncing around, etc, – then all the rendering and other stuff and, finally, if the sim has time, maybe, doing some script stuff. If some script is hogging the script time it’ll only, at worst, make the scripts in everything else react more slowly.

It has been this way for several years. The BIG impact scripts can have is when someone crosses sims (or teleports). Then the sims concerned have to pass a, potentially large, chunk of information between themselves. This used to cause the ‘sim freeze’ problem and although it’s been modified can still cause a slowdown when an avatar with loads of scripts arrives.

Now, researching even further:

There is a lot of misinformation surrounding scripts and lag. Terms like memory usage and regions resources are tossed about with very little understanding. Information from Linden Lab (LL) can be anything from lacking to highly technical to just plain old, out of date and hard to find.

Add into this a genuine desire to do the right thing by everyone and scripters selling products that proudly proclaim to fix a problem called lag that in reality is more like 12 very interconnected and very different issues.

The Basics

Simulator (or Sim) : The physical computer running in LL’s data center. Once upon a time sims were known quantities. A class 5 Sim was bigger and better than a class 4, it had a known number of processors and a known amount of ram. Linden Lab do not share the inner workings of their data center anymore, so it’s very fair to say what we do know is certainly out of date. Server computers are quite like home computers in that last years monster is this years door-stop. (Some information is sent to the viewer but it’s not used and not shown anywhere.)

Region : One ‘island’ of land running on a Sim, there are three types; Full, Homestead and Open Space. A Sim will run many regions at the same time. It used to be that you would get 4 full or 16 homesteads for every Sim, but I’m not so sure those numbers can be depended on anymore.

LSL : Confusingly, LL decided to name everything LSL (Linden Script Language) when really there are 2 sides. There is the human readable language the code is written in and the engine on the region that runs the code; There are two of these “engines”.

LSL Engine : The old engine, designed on the back of napkin and got the job done. Very clever but slow, a little inefficient. Very much showing it’s age. There is NO reason to ever create a script that uses the old LSL engine.

Mono Engine :The new engine. Very very fast, efficient, it’s had some bugs, but it has been updated and worked on a LOT. It’s a lean mean race car engine that’s bang up to date.

Script: A script is a bit like supermarket ready-mix cake and refers to the running code (recipe) and any data the code is using (ingredients). Only the scripts creator can tell you what’s inside the box, and just like cake mix, you get good and bad.

Region resources

We are not privy to what the lab do in their data center. We have some older confirmed numbers, nothing we can dependably rely upon. We do not know how much memory a sim has, or how much memory any given region is allocated. We have some numbers that are now years out of date.

It would be very fair to assume that the Lab can deploy regions on any hardware they like and there is no reason why they can’t give some more resources than others. Add in technology like virtual machines (a single computer running multiple virtual computers that all think they are the real deal) and it’s all pie in the sky.

This comes down to ‘fair use’ vs ‘efficient use’. A computer in a data center that sits idle is a waste. So while it may be fair to assume every sim has a set number of regions each with an equal slice of the pie, the reality is if those regions are empty all the time it makes more sense to try and use the spare resources and balance the load. The Lab recently announced that they would be making idle regions sleep, why? So other regions on the same hardware could use the spare resources and get a boost.

Regions have a lot of work to do, the majority of this work is keeping track of where everyone’s avatar is, deciding what data to send to you and handing the data your viewer sends back. The region does literally everything – the viewer is monumentally stupid. Example – You press up, the viewer tells the region that you have, the region then decides what to do and tells your viewer where your avatar is.

Pushing data about is the bulk of the work – Moving avatars, sending prims and textures. If you try to push more then the region can handle, then you’re in trouble. If the flow of data is interrupted or intermittent, you’re in trouble.

Efficient use is about maintaining an even quality of service. Ideally, Second Life should perform the same everywhere. From your perspective as an end user, it shouldn’t matter what sim the region is running on.

We are never sure how much of the pie a region has, and if you don’t know how much 100% is you can’t possibly say how much of that one script is using, let alone how much an avatar is using. We can guess. We will ALWAYS be wrong. The amount of work is only a problem with it exceeds 100%.

Script Resources

Time on a region is divided up into slices. A slice of time has a whole list of things to do the very last being scripts. These have the lowest priority on a region. If there is more script work to do before the end of the slice then it gets handed over to the next one.

A script by itself can not cause a region to lag, even one that runs constantly and works really hard. The worst it can do is delay other scripts from getting their turn.

A script that causes a lot of object updates can cause lag because of the amount of data the region has to transfer. Example; A script that causes a prim to change color rapidly or move around a lot. These are more likely to be part of the build rather than an avatar attachment. Turn on object updates in the viewer, the more blobs of color you see, the more work that object causes.

Script Memory Use

Old LSL Engine Scripts : Every script that uses the old LSL engine uses 16kb of data. Every time. The script can be long or short, it’s always 16kb and always bad. If you have 50 of them in an attachment, then that attachment is using 50 x 16kb of data (800kb). AVOID !

Mono Scripts

A mono script is more like a balloon. It has a maximum size of 64kb. But it only uses the amount of space in use. So a very short simple script could use as little as 4kb.

There is no way to tell how much memory a running mono script is actually using. This is by design. The Lab have provided some tools for scripters to profile memory use but they cause scripts to run up to 50 times slower, so only useful during development.

Finding out how much a script is using exactly really kills performance, so the lab have opted not to give us the tools to find out. Simply because we would use them in scanners and cripple a regions ability to process scripts.

Script scanners only tell you the maximum size of the balloon. There is a script command to make the balloon intentionally smaller just so scanners are able to provide an accurate figure. It’s new, no one uses it and it’s easy to make the balloon too small and burst.

So really, an attachment that has 50 mono scripts could be anything from 200kb (50×4) right up to 3200kb (50×64) ?

Probably. Mono is technically much smarter and has another big trick up it’s sleeve. It can split the script up into code and data. So if you have an attachment with 50 identical scripts it only needs to keep 1 copy of the code and 50 bits of data.

A mono scripted attachment with 50 identical scripts, like a resizer, could be as little as 4kb + 50 x the data. Lets assume 2kb, so 4 + 50 x 2 = 104kb

In any case, it will NEVER use the amount a scanner reports.

This gets even better as a resizer is an idle script, it isn’t doing anything unless you are actually using it. ZERO LAG POSSIBLE.

It is very true that this was a HUGE problem and the lab devoted a lot of effort towards limiting script memory, they then tossed all that work on the junk pile a couple of years ago and decided to try something else.

Very interesting reading, now for more facts about what causes lag:

Network Lag

​Network lag related to the network connection between your computer and the Second Life™ servers.

Downloading visible items and inventory items

Downloading avatar information to render them

Downloading physics information, avatar movement, object movement, collision data, etc. ​

Client-Side Lag (Viewer / Graphics Lag)

Everything that needs to be drawn (objects, avatars, etc.)

High Draw Distance – high draw distance increases the number of objects in visible range, therefore your viewer requires more memory, is more graphics intensive and requires more processing power.

High LOD (level of detail) – High LOD prevents the pre-planned decomposition and rendering of an object. Using the standard LOD setting helps prevent lag because pre-panned information can be used to help render objects. Using a different value for the LOD setting causes your viewer to re-compute information about each object to render it. Additionally, if the draw distance is very high the graphics card can render details which cannot be seen by the naked eye.

Object Animations – Any change of an object, such as texture changes, animation, color change, or movement causes the object to be re-downloaded.

Textures (bigger than 512px)

Particles (using large textures)


Light – Any additional light sources generates higher demands on the graphics card.

Server / Region LAG


Downloading (see Viewer-LAG) – Any Viewer-LAG items can effect the performance of a region. Each incoming avatar must download everything to the cache. Note Now that Linden Labs has instituted a distributed content store, downloading textures does not cause server / region lag.

Scripts – The number of scripts is not as important as what the scripts do and how much memory they consume. Why scripts are not listed as Viewer-LAG? Simple scripts that make visual changes are usually some of the smallest and cause a low load. That scripts by presence alone cause LAG is wrong.

Objects (rezzing) – Frequent rezzing can stress the region. Temp-rezzers which rez objects every 60 seconds are definitely LAG producing. Note, teleports by avatars also count as a rez.

Object Animations – ​Any physical movement of objects can stress the region, this includes vehicles of all kinds and pathfinding objects.

The most lag inducing thing in Second Life™ is Physics! The physics of a region is computed 45 times a second by the the region servers. Every avatar that is standing or moving and any objects that are moving contribute to the physics calculations.

As you can see, Scripts are the least culprits to cause lag. For SIMS to ask guests to remove their scripted items or be banned or ejected is based on false information. The culprits are Animations, Objects, Textures, Particles, Sounds to name a few. Before venues removes guests, take into account what is already on the SIM and how to reduce the over all lag first.


What's Your Reaction?


More From: news

Choose A Format
Trivia quiz
Series of questions with right and wrong answers that intends to check knowledge
Voting to make decisions or determine opinions
Formatted Text with Embeds and Visuals
Youtube, Vimeo or Vine Embeds
Soundcloud or Mixcloud Embeds
Photo or GIF
%d bloggers like this: