Eunoli Rain

Anyone with access to the Estate tools is extremely aware that yes, Virginia - script lag does exist.

Trinity Dejavu

If that box still does that (it might not after recent changes) then you need to poke Alexa Linden, there is a 'lag land' project underway. Basically a stated attempt to create the very worst of the very worst.

__________________
Catznip Viewer : www.catznip.com

Gabriell Anatra

I use llSetMemoryLimit in every mono script I write or work on as it usually helps get a better result in the various detectors. I have noted that two scripts will work in LSL despite requiring ~30k and ~50k to run in mono.

Not really sure why but they work better in LSL. The chimera, on the other hand, went from 240k to 9k when I was done with it.

Furniture, especially, benefits from conversion to mono as it never crosses sim borders anyway. The old bug was a memory leak. They did some work on it, but left some unfinished, from what I remember.

Marine Kelley

Actually this is because strings and UUIDs take 4 times as much space in Mono than they do in LSO. That's why LL increased the memory limit from 16kB to 64kB when introducing Mono. That wasn't an act of good faith, simply a contingency plan to the worst-case scenario. We being able to use more memory in Mono is merely a side effect of that decision.

So if your script uses lots of strings and/or UUIDs, it is very possible that it is smaller in LSO than in Mono.

__________________
90% of Sturgeon's law is crap.

Cerise

And this is absofuckinglutely critical at an event where the scripted vendors are the stars of the show.

Trinity Dejavu

Delay, not prevent.

The transaction is added to a queue, processing it might get pushed to the next frame, or the one after that or 20 frames after that but it will still be processed (even then we're still talking less than a second delay - The region runs at 45 frames a second on a good day.).

You get a transaction failure if it takes way to long to get to (over a minute I think), but that's pretty rare now and usually indicates a problem elsewhere.

You can also sell goods using a buy box that uses zero scripts.

Cerise

Top Scripts used to be broken, it used a bogus averaging method. That trouble was fixed a long time ago.

Trinity Dejavu

If you do use a lot of keys in a single script (advisable to benchmark)
Key Compression - Second Life Wiki

Void

you can say that again.... some of it in your own post.... whoops

like any complex topic, it's easy to get lost in supposed rules....

3 homesteads per core, last official word... since right about the time they split homesteads from "void regions"


not confusing... correct... LSL is the language you write in, LSO/MONO is the engine it runs on


Wrong! there are stills several good reasons to use LSO over mono.... and almost every one of them has to do with region crossing, and rez, and the response times to those occurrences.

unfortunately, even with all the holes they plugged this is still not true.... I know of two things that rely on neither object updates, nor physics that will still drop the region to a crawl, both of which are easy mistakes to make for users and scripters.... LL has worked on one, but has said the other will just have to be tolerated.

50 of any script is a sign of something being wrong. And while the base size in memory is fixed for LSO scripts, the code within them is actually smaller than MONO, by as much as 4 times, and as little as ~4/5. if you are using ~2/3 of that 16k, then on average your script will be LARGER in MONO

4k really is an absolute bottom... you might get 2 lines in it... common utility scripts average ~8K+... the numbers can be tested fairly accurately before hand to know, and may be slightly inflated by the testing functions.


even without knowing how large the scripts are, the number of them can be quite instructive, especially if they are within a single source.... every script is supposed to get an equal share of available time.... more scripts = more time (yes, even at idle).

not probably, factually. it's called byte code sharing, and it only applies to copies of the compile. this savings is NOT shown to users in any way, and if you do something silly like "recompile all scripts in selection) poof, it's gone.

a resizer does not need 50 scripts, it just needs 1... there's a dozen free ones available, some with tons of features.... in both MONO and LSO (MONO is much better here due to it's base processing speed)

correction, ignore memory totals for MONO, memory for LSO, and script counts are still valid markers that can indicate problems.

absolutely INcorrect... even idle scripts use script time, just much less than active ones, and they still use memory regardless

it's still a problem, just a much smaller one that previously.

Quote:

tl;dr We don't know how big the pie is, the slices of the pie could be anysize, they may not even exit at all. Anything that claims to tell you is MAKING IT UP.[...]

we don't know how big the pie is, but we do have plenty of tools to analyze the volume and weight of specific slices.... and while we don't know how big a slice that might be from the whole, we can take a reasonable guess based on the impact that it has on the region.

__________________
- These eyes can do more than see

Aribeth Zelin

I knew someone who knew much more on scripting could actually set the record straight. Yay Void!

__________________
Faerycat Designs In World -Marketplace 1- Marketplace 2

Joshua Nightshade

I was waiting for someone to do that; I knew various points were incorrect, but as I'm not a scripter I knowingly lack the technical basis to accurately explain why, and I didn't want to have a ten page back and forth with someone patting themselves on the back about how awesome they were because I wasn't explaining myself as well as a programmer would.

Salient point in all of this, though, remains that it's simply much easier to remove scripted items if you're going to a charity event with 50+ other avatars.

__________________

Void

There are two basic problems that LLL can do very little to contain....

the first is script count. script count matters because scripts get a fixed minimum of time to work in each frame... even idle scripts us up a small fraction. the more scripts that need to be run, the more minimums need to be met.... if all minimums cannot be met, then the ones that lost out last frame go first. this is the cause of script time dilation (making the script seem to run slower). While it is true that they will all still run, it's also true that they will all run slower, and slow or non-responsiveness is one of the key perceptions of lag.

the other is memory size. while various schemes can help this in some instances, they do not come without a cost. MONO seeks to limit it by reclaim unused space in LSO by using flexible containers, and byte code sharing. The cost there is that while MONO runs faster for most things (~10x), the way it is structured means it takes longer to set up (rez) and longer to transfer (region change). it is also very ineffecient in how it assigns memory for certain things (user functions for example) so a good portion of it's memory saving can get lost...

... But even with that, there is still an upper limit. once that upper limit is reached the system can no longer hold all the scripts in memory, and "swaps" them out to a container (page file) on a physical hard drive.... Hard drives are much slower than memory, and response time for everything takes a dive when memory swaps become frequent and/or large... LL has tried to combat this by adding script weight to the "prim count" (land impact) to encourage people to use less, but this doesn't apply to avatars, and they get a free pass in that calculation. which is kinda funny since I see single avatars walking around with more scripts than entire regions of rezzed content.

There is also a third problem, regarding some of the Input/Output interfaces which is half design problem, half equipment limitations... LL has done quite a bit to limit most of these problems, mostly by placing caps on how much and how fast certain things can send information, to prevent them from being flooded. Unfortunately it's one of the most common design issues in most scripts, and there are still some really big gaping holes in it that can cause anything from a single slowed script, to the whole region being slowed (yes even physics).

TL:DR
There was a time when I too bought the simplified version of "Scripts only lag scripts"... but the truth is that scripts can affect every facet: script lag, video lag, i/o lag, physics lag, etc.... fortunately I was around for the rollout of MONO and have kept a close eye on it's benefits and drawbacks... frequent rezzors (weapons mostly), and things that must work fluidly across region crossings (vehicles mostly) still benefit greatly from LSO. Scripts that run mostly code (as opposed to storage memory) that are near the 8k mark will be smaller in LSO, especially if they rely on several small user functions. High script counts are always bad for one reason or another.

Chalice Yao

And that's why I have a personal limit for each, script time, script memory, script amount.

Each is a seperate resource from each other. Each can be a problem by itself. Each can be fine while the other is too large or causes problems.

And I've taken each with a situation like a 50 avatar event in mind.

Script amount: 50
Script max memory: 3 MB
Script time: 0.25ms

Even if all three limits were to be reached by me, multiplied by 50 avatars that all use this max you still get

2500 scripts
150 MB memory (Total pool is 250 or 300 for scripts, I think)
12.5 ms script time

Which is a-okay for a busy sim. So if nobody is wearing scripts that do something stupid like send object updates or http calls nonstop, people gathering that stay within those limits should have no problem.
And it's easy to stay within those limits, unless the scripted items are old, or some of them just aren't scripted with efficiency in mind.

Usually I sit at around ~15 scripts, with memory below the 1.5 mb range. Still, I take scripts off for events, mainly because I know there will be people with +400 scripts and HNNNNGH script time around, and I don't want to burden the stressed sim further.

__________________
"Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?" - George Carlin

Grandma Bates

I am not quite sure what "this" is all about, but it seems clear that there is some sort of context. (I am grateful to remain blissfully ignorant thank you very much...)

Anyways, the other sin committed in the original post but is alluded to above is that it assumes a static situation. When an agent hits the sim the stack for each non-unique script and the heap for all scripts need to be sent to the core. It goes through the network stack so it takes up bandwith and the server takes a hit.

The other issue is that when those scripts come in they have to do an analysis to sort out which events need to be added to the queue. All that takes time and resources.

Finally, the memory has to be managed. The mono vm is more aggressive with respect to trying to keep memory contiguous, and that means the core is trying to shift memory around. The cores act like a shared memory machine so that takes up server resources. When a new script comes in it shakes up everything.

As agents move in and out of the sim then all this can be a nontrivial hit on resources. Multiply that by the number of scripts, and it adds up quickly. The original analysis assumes a static situation. That is not what SL is a about, and people expect to land on a sim and have everything come together instantly.

__________________
"From this proposition it will follow, when arithmetical addition has been defined, that 1+1=2." - Principia Mathematica, Russel and Whitehead, page 379 (1st ed.)

Joshua Nightshade

There's presently a charity benefit sale going on for the poor girl whose skin line was copybotted, and the copybotter filed a false DMCA (or some sort of legal action) against the legitimate creator, locking her out of SL for several weeks now. As the legitimate creator relies on SL income for her RL job she's been without funds and in financial trouble while she deals with the brazen actions of the copybotter.

Trinity (and a couple other people, like Darien) teleported to the sim in normal couture and were ejected by the security system that had to be implemented because billions of scripts crashed the charity sim for three hours. She whinged about how script scanners are bogus and there's no such thing as lag anymore (despite the fact that since implementing the script-ejectors, the sim hasn't crashed at all) and started this thread as an extension of her entitlement. She, Darien and a couple other people were mortally affronted that they were asked to reduce script usage before teleporting in, and were teleported out for failing to do so. They took it as a personal attack on themselves, their creative expression, and their belief in Jesus Christ.

Penny Patton

This just kills me.

First off, I do believe having some kinda limits on scripts, similar to how we have limits on prims, would help. But to combine them? Right, because SL needs to look uglier than it already does. This seems like it is going to do more to limit how interesting environments can look than it's going to reduce script related lag.

Second of all, yeah, avatars getting a free pass. Plenty of times I've seen a single avatar unwittingly bring a sim to its knees.

__________________
The Digital Pasture - SL from a cow's point of view. When the cow is also a designer.

Joshua Nightshade

Yeah, avatars continue to be the worst offenders in prim count, script usage and textures.

Trinity Dejavu

The post is aimed at people who are NOT scripters.

Pretty fair chance people might have heard what LSL is, no one knows what a LSO VM is. Same reason why people say "the sim is down" when in fact they mean the region and everyone's mom thinks the big box that holds the computer is the HD.

There comes a point when trying to get everyone using the same words is more then enough to turn your audience off. That might incur the odd technical inaccuracy or misused magical acronym. The intent here is to inform rather than dazzle.

This is based on the single assumption that LSO and MONO are equal in all but size. MONO has a significantly lower overhead than LSO so while you can make a 16kb script in one that might be 25kb in the other, the mono script is still much lighter on the region and always more efficient.

With LSO the size of the code inside the script is irrelevant. It takes up 16kb of memory every single time, the extra empty space is just that, empty.

Empty memory is wasted memory that could be used for something else. Yet it requires exactly the same amount of cpu time when being manipulated.

An idle script, that is, a script with no pending events, is such a tiny burden on the region as to be insignificant next to the avatar it is attached to. Of course it would be better if it didn't exist but there comes a point when better has to be measured in terms the user is capable of perceiving.

This is something that comes up doing viewer development, we see a bit of code, a bit of XML that could be done better, smaller, faster. Even if that code gets run 50 times every second, making it better might have such negligible impact that it's best forgotten about. Otherwise it's months of work and all we've accomplished is feel good factor.

That's misleading and confusing. Beyond being able to say this one is bigger than that one we really have no clue. Weight is relative and can change so dramatically so quickly as to make measurement very hard with the tools we have. Half educated guesswork is not the basis for doing anything.

Measuring script performance and memory use is very expensive and there is a huge difference between what you can do during development and what someone can do peeking at things live in the field.

Top scripts only shows spread average figures, which I suspect has more to do with people hitting refresh over and over than presenting actual technical data to an estate manager.

If you put 40 avatars on a region with high object updates - like a club with flashing lights. Then you just maxed out the region. The number of scripts and the work involved in processing them is trivial in comparison. Especially with the region changes aimed at keeping the frame time stable and not allowing a script to cause an overrun. Time dilation isn't dead, but it's a lot closer to it than it used to be.

The recently announced LL war on lag, most notable by it's absence - scripts!
Project Shining to Improve Avatar and Object Strea... - Second Life

Trinity Dejavu

There are limits on scripts, they're now limited on the region in how much time they can use (this has always been the case, however it was poorly enforced / broken). There are of course exceptions which doesn't negate them all-together. Memory limits as a project was put on the back burner years ago.

The combined script prim mesh land impact nonsense has been overhauled and is now live on path-finding regions. Expect the land impact of scripted meshy things to drop significantly.

The decision to combine script and land impact was probably intended to create a simple end user experience more than anything else. This house is 34 thingies, I have 80 thingies free, yay, it fits.

Anouk

Please excuse my ignorance on this - I pretty much know how to check what total scripts my avi is running at any one time - either via SL menu options or just by jumping on one of those script weighing jobbies at a lot of places (I even have one at home to ensure that I don't unwittingly drag too much shite with me if I go somewhere that's likely to be busy - my colour changing fingernails and rings being a prime example). However, so far I've been unable to find any way to pinpoint the numbers of scripts run by each individual item. I'm aware of the usual suspects (ie, boots, hair etc and always make sure I delete scripts once I've finished re-sizing). But it would be useful to have some way of seeing all the scripted items running on my avi, in case I may have some new item that is particularly heavily scripted that I may not be aware of?

Or is it just a case of going through everything upon the avi by trial and error?

Enquiring minds want to know....

__________________

Argent Stonecutter

I've never seen a server referred to as a sim before.

Sim - The software that implements the server side of Second Life.
Region - What is simulated by a sim.

Each sim runs a single region, as well as providing inventory services for in-world objects on that region, web services for scripts in the region, and communications between regions. A server runs multiple sims.

__________________
Argent Stonecutter -- Skyhook Station -- Coonspiracy Store

"And now I'm going to show you something really cool."


The previous is a cybernetic datum published - in direct contravention of DoD Regulation #229RR3X3 - as being conducive to the physical, psychological and/or social well-being of the population.

Trinity Dejavu

The point of this post is make it clear that the numbers being reported in the viewer and by script scanners is inaccurate to the point of being irrelevant. SL does lag from time to time, some like to point fingers and script memory makes it easy to do that.

As an end user you shouldn't have to worry about scripts. It's probably to much information that you know they exist at all.

This is good practice, it would be better if the creators of your boots sold them modify then you wouldn't need any scripts at all.

Some third party viewers have this functionality. However, the act of looking is a very intensive.

Basically what happens is the viewer fetches the contents for every prim one by one then adds up the number of scripts it finds on the way. This causes load on the region. Get a few people doing it at a club on other avatar attachments and it creates more load than the scripts they are counting.

KT Kingsley

From the About Land floater select the General tab, and from that click on the Script Info button, and the select the Avatar tab. The resulting list will tell you what scripted items you're wearing, how much memory each is using (yeah, yeah – there's issues with the actual numbers there, but almost always the bigger the number the more the scripts) and where you're wearing it. But not the number of scripts, though sometimes it's possible to figure that out from the reported memory usage - but not reliably.

(To get the About Land floater up, either right click on the ground (and not a floor prim), click the About Land button on your toolbar – if you have it there – or chose it from the World menu in the main menu bar – it's called Parcel Details in the Firestorm menu, presumably for the sake of clarity.)

To find the number of scripts in an individual item, I guess you'd have to take everything off except the item in question and use one of those script counters.

Argent Stonecutter

Also, LSO scripts have lower performance, but significantly lower overhead, and while they always use 16k they never use more than 16k. If performance is not critical, if the script is spending most of its time idle (that is, it's not doing real-time puppeteering or raytracing or something like that), and it fits in 16k, then you should use LSO.

This is particularly true for things like AOs: a good AO can with care fit in 16k, and a 16k LSO script will be using at least 30-40k in mono.

My avatars that are all LSO typically have about 80k script usage and negligible script time. The ones that have some Mono scripts (because the creator thought his blink script or jaw script was so special it had to be protected :eyeroll: ) are 500k on up.

Trinity Dejavu

Intentionally trying to limit technical terms. Until you tell someone a server is a type of computer (like an SUV is a type of car) they have no idea.