Whatever happened to script limits?

[Ansariel Hiller]

---

Dresden Ceriano wrote:

But... is my thought that simply reducing your number of scripts will end up reducing your memory usage valid?

...Dres

---

In general: Yes. Or recompile LSL2 scripts as Mono scripts. Basically, my intention was to point out that the fuzz being made about script memory by using those script memory boards is pretty much pointless. As example, run this little script both as LSL2 and Mono version:

default{    touch_start(integer total_number)    {        list props = llGetObjectDetails(llGetKey(), [OBJECT_SCRIPT_MEMORY]);        llSay(0, "Memory used: " + (string)llGetUsedMemory() + " Bytes");        llSay(0, "Memory reported: " + llList2String(props, 0) + " Bytes");    }}

 

[Innula Zenovka]

---

Dillon Levenque wrote:

I understand what you wrote but I am still not sure whether my script scale is useless or not. Just to be clear, I call it 'my' script scale because I bought it (for 0$L), not because I created it.

It counts the number of scripts I'm dragging around as well as [what, apparently, is the best guess as to] their total memory usage. Let's assume the number of scripts it reports is accurate. Without naming the creator of my scale (which I can't do even if I wanted to right now since I'm not inworld) is it possible that he or she has just used 64K as a default? If so, why would my memory usage show over 3MB with one collection of scripts but under for a different collection with as many or even more scripts?.

Even more to the point: if my script scale truly is useless, how does one make a real determination? The ratio of SL residents who are clueless about scripts to those who write scripts has to be close to 1000 to 1 if not greater. A lot of residents don't even know what scripts even are. What's the answer? How does a person know if he or she is causing a problem?

---

I hope Qie doesn't mind my chipping in here.  The function your object must be using, llGetObjectDetails, can report on four things about scripts -- the number of running scripts there are in an object, the number of scripts, running or stopped, there are, the average amount of CPU time the scripts are taking up, per second, and the amount of memory the sim is allocating to these scripts, not the amount they're actually using.    It's this last figure, OBJECT_SCRIPT_MEMORY, you're talking about.

Note that, as the Wiki says, the figure reported by OBJECT_SCRIPT_MEMORY represented by   " the total amount of script memory allocated to the object or agent, in bytes."  In the case of an old LSL script, the amount allocated to the script and the amount its using are one and the same, 16 kilobytes.   In the case of a mono script, however, the sim will -- unless otherwise instructed -- allocate 64 kilobytes to the script, unless the scripter has used llSetMemoryLimit to set a lower limit.   

However, as Qie explained above, there's not a lot of point in the scripter using llSetMemoryLimit because the sim doesn't reserve the allocted 64 kilobytes to that script -- the script can use, or not, as much memory as it needs at any one time, up to either 64 kilobytes or whatever limit the scripter has set.     The only advantage -- since script limits were never introduced -- to using llSetMemoryLimit, at least that I can see, is that it keeps script counters happy.

So the reason your memory usage is showing as higher with one set than with the other is almost certainly that one set has more LSLO rather than LSLMono scripts than the other.   It's almost certainly not, though, an accurate indication of how much memory your Mono scripts are actually using at any one time.

As to how do you know if you're causing a problem, that's a bit hard to answer.   One or two people on their own aren't likely to cause a problem under any normal circumstances.   However, at a busy event (skin fair or hair fair, for example), where you've got lots of people arriving and departing, if they've all got a script count that would be not-inappropriate for a  quiet sim with 5 or 10 people there, you may well see problems. 

It's maybe useful to emphasise that script memory and script time are two completely different metrics, and that the sort of problems caused by scripts using too much memory are completely different from ones caused by scripts using too much time.     It's maybe also worth pointing out that, in general, neither script time nor script memory are by any means the main cause of poor sim performance or perceived lag.   The first thing I would look at, for example, if a sim is having problems is the number of physical collisions that are being reported.

My personal rule of thumb is to try to keep my script count below 50 and my memory usage below 3 MB  (3072 kilobytes), which I don't find particularly demanding even though I always wear a scripted collar and use a scripted AO.   This has the practical advantage of making tp-ing somewhat easier, but the main advantage, to my mind, is that it keeps me within the limits most owners of script counters seem to use, so I don't get shouted at by orbs.

[mikka Luik]

Have to add a bump (ok a little rantette) about OBJECT_SCRIPT_MEMORY because as it stands its - less than useless in what it returns. For my own satisfaction I have played with setting Mono memory just out of curiosity, to see what can be done with an 'overhead' limit, however I have refused point blank several requests to make 'memory indicator boards' simply because the granualarity of actual usage isn't there. Hence the somewhat arbitrary limits (oh such shades of ARC =^^=).

Short version - if I can do it in one Mono script, I will.

[Innula Zenovka]

I agree.   I have a script counter/memory checker at home, which I use to check outfits -- primarily, as I said, because I don't want to get shouted at or kicked by people's security orbs.   I would not, however, dream of using a script checker on visitors  to a sim, at least not under normal circumstances.

At one group of sims where I'm an admin we did have a checker, just so people could see what they were using, but we got rid of it because it was causing too much drama and ill-feeling.

[Paul Hexem]

While you shouldn't rely on reported script memory to make your decisions, you can rely on script count and script time to be accurate, I've found. So if all three are high, it doesn't matter if the reported amount of memory isn't correct. You can still be fairly certain that it's not low.

 

The problem with those boards is that they often don't consider all three numbers, and they're often set with very low limits.

[Dillon Levenque]

Thank you for the explanation. I suppose I'll just keep doing what I've been doing but place more emphasis on keeping the counts low rather than the usage.

[Ciaran Laval]

I think the problem was implementing the script limits in a helpful way and whether the overheads from that implementation would cause more problems than it solved.

The one big argument was the dynamic nature of scripts and how they may need to temporarily grow but would then drop back down quite quickly in terms of usage.

[Qie Niangao]

---

Gadget Portal wrote:

While you shouldn't rely on reported script memory to make your decisions, you can rely on script count and

script time

to be accurate, I've found. [..., emphasis mine]

---

If one knows what one is doing, script time is a good measure but it, too, requires some interpretation. Whether script time is observed from a measurement script or directly from the sim console, it will always show a (very) inflated number for a new arrival--and a number that is not in any way predictive of steady-state usage. Specifically, two avatars arriving exactly simultaneously, one with a higher script time than another, may have those numbers reverse in a minute or so.

I'm using "inflated" to describe these numbers but in fact they accurately report what's going on, it's just that what's going on when scripts enter a sim is dynamic--and expensive. It's also somewhat expensive for scripts to leave a sim. Hence, about the worst thing to do on an already busy region is to boot a vistor for being too scripty, then have them come back with slightly fewer scripts, boot again, and repeat until they satisfy some mystical scriptiness ceiling.

[Paul Hexem]

Right, you gotta give it time to settle down.

[Czari Zenovka]

What would be the best way, from a scripter's perspective, for the average SL resident who knows little to nothing about how scripts operate *but* who does want to be responsible in what they can do to lessen their personal scripts.

I currently take all scripts that I possibly can out of hair, shoes, jewelery, resizeable clothing, etc.  (After first making a "Master copy" to archive and having made any changes the scripts provided.)
I also have a script meter I check my avatar against after putting an outfit together.

Is there anything beyond these measures I, and others, can do to help lessen lag within SL?

[Melita Magic]

There is one place I have some land where I own half the sim and half is owned by someone else.

Seems they have a lot of scripts running. Orbs, trackers, radar, who knows what else. Vendors, etc.

Sim has been suuuuper laggy lately. I just hope it isn't me, but other than some breedables the land group doesn't have anything that scripty on my side.

[Innula Zenovka]

All the scripts are going to lag are other scripts,  so I'm not sure that's an issue.   Simply saying the sim is very laggy doesn't really say very much, since there's so many different things it could be describing, and those could have very different causes.    

Breedables always worry me a bit -- just to rule out possible problems, I would -- if you have access to it -- check the top collides in the Region/Estate debug tools, just to make sure that your breedables aren't generating a horrible number of collisions.   On one sim where I am an admin we did that, and pinpointed the cause of really bad sim performance that had baffled us for weeks -- it was a couple of physics-enabled critters that were wandering around lost somewhere colliding with each other and lots of other stuff.   Once we disabled those, things started to get back to normal.

[Melita Magic]

The animals are phantom (If that matters.) I did notice someone was getting their pen a bit...crowded lately. Gonna have a word, I think.

I'm not sure how to check that other thing. I've checked sim things before but always forget. I don't have much innate ability for such things. Maybe someone can shoot me an in world IM on how to make sure I'm not a script hog, or a note card, or something, if it's too off topic to post here.

And if they have time and the inclination of course. I don't mean to beg for help on here. It was more an idle thought.

I do have some fish that rotate and things like that. Some of those are older creations so maybe those are causing problems too? Been thinking about redoing the whole beach lately, especially since I had to re terraform again recently.

[Innula Zenovka]

If they're phantom they shouldn't, I think, be colliding with each other.  I can't remember offhand if they generate land collisions.   Check anyway -- it's in the same place top scripts are (our critters weren't breedables -- they were a crab and something else that someone must have rezzed and forgotten about).

[Melita Magic]

Hmm, I do have crabs and such (eta: on the sea floor! on the sea floor!), and an aquarium; some of it doesn't belong to me, but to a friend making permanent loan when I had no clue how to decorate that much space.

A lot of the sea life is so tiny no one can see it unless they are right on top of it. That was part of the (initial) intent, so people felt they were discovering as they went. But visitors have dwindled lately and it's time to think more about functionality.

Thank you sincerely, for all of your help and information.

[Jenni Darkwatch]

Memory use is indeed bogus as residents can't see the true memory use of any avi or object.

Script count is interesting in many different ways:
* Scripts have finite time to execute, meaning the more scripts run the more likely it is to cause time dilation on all scripts.
* The number of scripts one lugs around affects TPs and sim crossings directly. Those scripts need to be transferred to the new sim, which takes time. Try this: Cross sims over the corners with no scripts... then do it with many scripts.

Script time is somewhat in the same vein as script count. It starves other scripts for execution time.

At least in theory, scripts should not lag avis. Practically they can insofar as script mem use could cause the sim to start swapping memory.

To some extent this also explains why in most cases one single script is superior to having a multitude of scripts. Especially vehicles benefit from this because it makes sim crossings a lot safer.

[Qie Niangao]

---

Czari Zenovka wrote:

What would be the best way, from a scripter's perspective, for the average SL resident who knows little to nothing about how scripts operate *but* who does want to be responsible in what they can do to lessen their personal scripts.

I currently take all scripts that I possibly can out of hair, shoes, jewelery, resizeable clothing, etc.  (After first making a "Master copy" to archive and having made any changes the scripts provided.)

I also have a script meter I check my avatar against after putting an outfit together.

Is there anything beyond these measures I, and others, can do to help lessen lag within SL?

---

I kind of lost track of this thread. Sorry about that.

There's really not much more you can or should do about avatar-based script lag. It's not necessary to really obsess over this. As Innula mentioned, scripts are only rarely a significant factor in perceived lag; hence, as long as there aren't big surprises in the number of scripts in an outfit, you should be fine. (Such "big surprises" might arise from wearing old hyper-scripted shoes, for example--some notoriously No-Mod--so that practice of checking a script meter is prudent.)

There are other kinds of lag, of course: 

• Avatar-based non-script lag (stuff that's hard for viewers to draw, hints from Advanced / Performance Tools / Show Draw Weight for Avatars)
• Non-avatar-based script lag (too much scripty stuff rezzed out on land)
• Non-avatar-based non-script lag (everything else rezzed on land that's either hard for viewers to draw or uses lots of sim time with collisions, etc.)

I don't know that we want to attack each of those in this thread. I'll just say that Develop / Show Info / Show Updates To Objects is often useful for discovering unsuspected lag sources on land.

[Penny Patton]

Texture maps are a huge source of lag that many people overlook. 

In designing environments for SL, I'm regularly encountering content using 1024x1024 texture where 512, 256, or even 64x64 texture would result in such negliglbe quality loss that I'd wager even the original creator would be hard pressed to tell the difference.

 This hurts performance in several ways.

 First, your videocard needs to process and render those textures, eating up your video memory and putting more strain on your video card to render SL.

 Second, SL needs to download all those textures, which results in lengthy load times and constricted bandwidth leading to latency issues.

 And, of course, server side lag as SL has to send all of these textures off to, not just you, every every single avatar rendering the same scene.

 

 If LL factored texture use in LI cost calculations, and made an attempt to educate people on how textures affect performance via the upload tools and costs, then SL would run much more smoothly for everyone.

Texture use does seem to be factored into avatar draw weights. I've reduced my own considerably by resizing my textures.

[Qie Niangao]

Total image size is one thing that I think should ideally be limited, similar to Land Impact. It's too late to shove it into the Land Impact calculation (already too much a grab-bag metric), but this is a long-standing problem that's about to get three times as bad with the addition of normalmaps and specularmaps.

[Penny Patton]

It's arguably too late to add texture use to LI calculations now (I'm not entirely convinced it's not worth the possible outcry considering the long term benefit) but they could have slipped it in when LI was introduced and it wouldn't have been an issue.

LL wasted a huge oppertunity with mesh. That could have, and should have been a game changer. New object asset (mesh), the introduction of land impact, a rush of new content. They could have fixed most of SL's problems and ensured their future if they understood their own product enough to really follow through some of those changes.

 

 This is what happens when you try to develop a graphics engine slash creation tool without any guiding input from artists who understand how graphics and content creation work.

[Jenni Darkwatch]

I'm not entirely sure they didn't discuss adding such limits. It's a fine line, even as it is there's still a lot of creators preferring sculpts over mesh because of the lower display weight (when rezzed as prim), especially for large landscaping objects.

With textures they can and do futz a little on the client-server communication level, i.e. the client won't always request the full size texture anyway and hence the graphics engine won't display it either. I'd guess that mechanism made it an easy choice: Hamper mesh adoption even more by imposing stricter (if sensible) limits or let some bad practices like monster-sized textures slide?

An example would be the obiquitous textboards. Especially the 2-letter per face ones use massive amounts of textures. If they had penalized textures, no one would make 8-faced mesh to replace the much more render-intensive (and physics-intensive) 5-faced sliced and diced box prim.

SL has to live with some bad decisions that were made early in its development... I'm not sure there's going to be a good way to fix most of these.

[Czari Zenovka]

---

Qie Niangao wrote:

---

Czari Zenovka wrote:

What would be the best way, from a scripter's perspective, for the average SL resident who knows little to nothing about how scripts operate *but* who does want to be responsible in what they can do to lessen their personal scripts.

I currently take all scripts that I possibly can out of hair, shoes, jewelery, resizeable clothing, etc.  (After first making a "Master copy" to archive and having made any changes the scripts provided.)

I also have a script meter I check my avatar against after putting an outfit together.

Is there anything beyond these measures I, and others, can do to help lessen lag within SL?

---

I kind of lost track of this thread. Sorry about that.

There's really not much more you can or should do about avatar-based script lag. It's not necessary to really obsess over this. As Innula mentioned, scripts are only rarely a significant factor in perceived lag; hence, as long as there aren't big surprises in the number of scripts in an outfit, you should be fine. (Such "big surprises" might arise from wearing old hyper-scripted shoes, for example--some notoriously No-Mod--so that practice of checking a script meter

is

prudent.)

There are other kinds of lag, of course: 

• Avatar-based
  non
  -script lag (stuff that's hard for viewers to draw, hints from Advanced / Performance Tools / Show Draw Weight for Avatars)
• Non
  -avatar-based script lag (too much scripty stuff rezzed out on land)
• Non
  -avatar-based
  non
  -script lag (everything else rezzed on land that's either hard for viewers to draw or uses lots of sim time with collisions, etc.)

I don't know that we want to attack each of those in this thread. I'll just say that Develop / Show Info / Show Updates To Objects is often useful for discovering unsuspected lag sources on land.

---

Thank you so much, Qie. :matte-motes-smile:

[igraine Blackadder]

How do you find how many scripts you're wearing? There isn't a script check on my sim.

 

[Innula Zenovka]

As to the specifc question about what happened to script limits, I think the idea was quietly dropped when Babbage Linden (who was the scripting Linden working on the project) left back in 2009 or 2010.

Nowadays I try to stay out of arguments about the effects of multiple scripts -- it's a complex and highly contentious topic about which scripters far more experienced than am I can't agree.   FWIW I usually follow Qie's advice in such matters.

My broad view is that, in general, fewer scripts is a better idea.   However, one badly (or malicously) written script can do far more damage to a simulator's performance than can a whole load of passive resizer scripts in an old outfit, since script memory and script activity are two completely different things, and too much of either can adverstly affect the region's performance in different ways.

Generally, I'm far more worried about the effects of badly-optimised meshes and textures than I am about the number of scripts someone is wearing.