Q Lag monitors, memory use and mono scripts

[PeterCanessa Oh]

For those cases where I know I'll be resetting, or at least don't want/need to keep script state, I use script-repository objects within the main object's contents.  These objects hold the scripts which, being contents of contents, are not rezzed or active so take no memory or processing.  To activate the functionality of a script I rezz the repository object (so rezzing rights required and there's quite a bit more processing than just setting the script state flag).  The repository object communicates with the parent and either does the processing if it's a one-off or passes the script to the parent (llRemoteLoadScriptPin()) for continued operation - then it deletes itself.  What all that work leads to is that the script in the main object can be deleted rather than just disabled when they are no longer required.

It's not a good method for objects that will be adding and removing functionality frequently or need to do it very quickly but it does give a very low memory/processing profile for rarely-used functionality.  As an example there can be pretty complex initialisation routines (notecard reading, configuration, web-site synchronisation/updates) that only need to be run once when the main object is rezzed/reset.

[Jenni Darkwatch]

---

Kwakkelde Kwak wrote:

There are a lot of worn and rezzed lag monitors around and I had a question about them.

I use some items (not my own) that have a large amount of mono scripts in them, purposely set to mono for faster execution. The memory use, as I understand it, can be anything from 0 to 64k opposed to the set 16k for an LSL script.

The lag monitors, again as I understand it, read the full 64k for the monoscripts instead of what they actually use. Using the estate tools I can see I produce little lag (script time anyway, around 0.3 ms usually), yet the monitors always show me as very laggy (in memory I guess).

---

0.3ms for scripts on an avi is somewhat in the upper range of "acceptable", IMO, considering one frame on a simulator only has 22ms. However, since the simulator throttles scripts first thing it runs into timing problems, I'd consider script time to be fairly irrelevant in most cases (busy venues aside).

Unfortunately the way script time works is that it "settles" over time, meaning when an avi TPs in, it's going to be high. Check 5 mins later and the value is more accurate.

Memory... yes, that's a problem. Any measure of script memory is going to be skewed for mono scripts, as it is right now. The suggestion about using llSetMemoryLimit()... I really should start using that myself. Even dynamically adjusting memory limits should be fine IF it's not done every second or so. Just IMO, haven't tested it.

[Kwakkelde Kwak]

---

Jenni Darkwatch wrote:

0.3ms for scripts on an avi is somewhat in the upper range of "acceptable", IMO, considering one frame on a simulator only has 22ms.

---

Since SL is a social platform the way I see it, using half the available 22ms for avatars sounds lowish to me. If everyone was at 0.3 that would allow almost 40 avatars without any throttling. I wouldn't call that on the upper range of acceptable, I'd call that well within reason.

 

---

Memory... yes, that's a problem. Any measure of script memory is going to be skewed for mono scripts, as it is right now. The suggestion about using llSetMemoryLimit()... I really should start using that myself. Even dynamically adjusting memory limits should be fine IF it's not done every second or so. Just IMO, haven't tested it.

---

Yes I was thinking of something like that myself, executed not on a timer, but before or after certain script commands. It's a lot of work though, only to give more accurate figures to the sim (so also to the lag monitors) without actually saving any resources.

 

 

[Jenni Darkwatch]

True... it's additional work for little direct benefit. I think it's worth it though, so I'll probably add that to my workflow for future scripts. And my own HUD, too (it's free and fullperm - if you want a copy, feel free to holler).

[Kwakkelde Kwak]

Ok...I was going to say mono scripts seem to use three times more memory than LSO scripts.... so the script would have to be either pretty small or pretty big to be better compiled in mono (for memory use).

But I looked the mono benefits up in the wiki and if you use more than one, the script data is shared and only used once, so in for instance a store with a LOT of duplicate vendor scripts, mono is preferred easily.

This brings me back to the lagmonitors.... I bet they don't pick up on duplicate scripts. Anyone who wants to comment on that and enlighten me?

[Jenni Darkwatch]

Nope they do not pick up on that.

[Kwakkelde Kwak]

---

Jenni Darkwatch wrote:

Nope they do not pick up on that.

---

Thanks for verifying that.

Now I also bet when (or if) script limitations are going to be introduced, the sim WILL pick up on that. In other words, there has to be a way to sense the duplicates. Maybe it's time for a better script function than the one currently available for fetching memory use by avatars. Or maybe LL is already working on that as "a next step" towards the limitations (which I sincerely hope will be implemented at some point).

[Jenni Darkwatch]

It would be great to get better/improved tools for scripters and land owners to determine what exactly is going on in terms of performance. Not just with script use, but e.g. also with avatar use. For example, you cannot currently get any download weights for avis, while you can get them for all objects easily.

The addition of scripted abilities to get _some_ information is, IMO, a good step in the right direction. That there are limitations and quirks would not be so bad if they were easy to understand.

[Kwakkelde Kwak]

The download weight is partially reflected in the avatar draw weight. The download weight, or streaming weight as it seems to be called in the wiki, is based on the size of the object (how many people can see it and at what LOD) and the number of bytes a certain file costs to stream by itself (that would be pretty much 100% geometry and normals I guess). The draw weight is this number with a couple of modifiers applied for shine etc. The only thing completely not shown is the amount of texture memory I think. Shouldn't be too hard to include that I guess.

 

Oh another question more related to my OP... If a mono script is used twice, the second will only have the weight of  "a script" on the RAM. Is this still the case if the script reads a notecard or has variable ehm variables (integers or strings or whatever that change as the script runs)?

[Qie Niangao]

---

 If a mono script is used twice, the second will only have the weight of  "a script" on the RAM. Is this still the case if the script reads a notecard or has variable ehm variables (integers or strings or whatever that change as the script runs)?

---

The only part of memory that's shared among instances of identical Mono-compiled scripts is the script program itself, not its data memory.  When you think about it, that's kind of obvious: those script-specific strings, lists, etc have to live somewhere.  So, really, for the vast majority of scripts the sharing just doesn't help all that much because so much of the memory is in the data, not the program itself.

Also, to an earlier point: I wouldn't bet too heavily on the shared memory ever being factored in to script memory limits. The more or less insurmountable complexity there is that those instances may come and go -- and because the memory is allocated per parcel but the sharing is per sim, it's possible for a script to be deleted on one parcel and push another parcel over the memory limit.  

I guess, theoretically, the sharing benefit could be artificially constrained to per-parcel, thereby sidestepping this problem, but to be honest, I wouldn't expect it to be worth cluttering up the sim's parcel representation any more than it is already.

[Kwakkelde Kwak]

---

Qie Niangao wrote:

The only part of memory that's shared among instances of identical Mono-compiled scripts is the script program itself, not its data memory.  When you think about it, that's kind of obvious: those script-specific strings, lists, etc have to live

somewhere

.  So, really, for the vast majority of scripts the sharing just doesn't help all that much because so much of the memory is in the data, not the program itself.

---

Ofcourse, that IS obvious, but it was indeed the script code I was asking about. Next question pops into my head... Does anyone know what "a script" costs? When you make the most basic of scripts it already costs quite some memory. More than I think the code in that small script uses...just curious

 

---

Also, to an earlier point: I wouldn't bet too heavily on the shared memory ever being factored in to script memory limits. The more or less insurmountable complexity there is that those instances may come and go -- and because the memory is allocated per parcel but the sharing is per sim, it's possible for a script to be deleted on one parcel and push another parcel over the memory limit.  

I guess, theoretically, the sharing benefit could be artificially constrained to per-parcel, thereby sidestepping this problem, but to be honest, I wouldn't expect it to be worth cluttering up the sim's parcel representation any more than it is already.

---

As far as I recall the limit was or is supposed to be per parcel, but this is really inefficient use of available memory and the exact opposite of what LL has done with shared CPUs for homesteads and open space sims. So I think you are completely right here, it probably won't be implemented that way.

 

 

[PeterCanessa Oh]

Kelly Linden has said in an earlier post in this thread, "For additional clarification the smallest script in mono is just under 4k, the average mono script is approximately 9k. All LSL/LSO scripts use 16k.".

I don't know how much the actual code for a minimal 'hello world' takes of that 4k though and how much is left over for data and more useful code.

[Lear Cale]

The smallest program segment was 512 bytes, last I checked (and I *really* wish they'd reduce that!)

Every state takes at least one program segment.

Every function takes at least one program segment.

The minimal script might also need some fixed number of program segments.  Each state might take one as well, but I never tested that.

So, the minimum program size is 512 (for one small event handler in the default state), plus whatever the per-state and per-script overhead is.

 

Someone above mentioned that in Mono scripts, it's the data that takes most of the room.  That may be typically true, but isn't the case for some scripts.  For example, my Spin The Bottle game has a surprisingly large amount of algorithmic code.  (The worst case is to handle the multiperson case; given each player's sex and sexual preferences and a list of possible poses, with the role of each poseball coded, finding the candidate poses that are possible given the players present, and after selecting one, randomly assigning the applicable players to each poseball.  Which is trickier than it sounds, unless you're a genius and have some metamathmagical trick up your sleeve, which I am not and do not.)