Scripts Running on Land Excessive?

[casey Crisp]

When checking scripts usage on my 1024 bellisseria plot, I found a number of furniture items that were running huge sizes, tho most were in the 64-300ish range.  I don't notice any lag, but is this something I should be worrying about? It seems most of the furniture I like seems to have the highest script count.  Is there a total number I should be trying to staying under for a 1024 plot?

[Qie Niangao]

I'm not sure there's a handy tool for assessing this (I use an ugly script I hacked myself), but the more important measure is the amount of time spent by an object's scripts, with a secondary measure the script count. (Script memory is an almost totally misleading number as calculated outside the script itself, conveying no actual information beyond count.)

Script count mostly matters because of the way scripts are run, where totally idle scripts burn a little scheduler time just to decide not to run them. And unfortunately, most furniture animation engines including AVsitter contain ridiculously many scripts, partially to hold many animations, and partially out of a misguided "modularity" of features into separate, communicating scripts. But this is a platform-wide problem and there's not much difference an individual landowner can make. I sometimes delete AVsitter scripts for features I know aren't going to be used (faces, for example, is pretty obsolete since mesh heads became ubiquitous), but it won't much matter to sim performance.

Anyway, if you can measure script time of an object you may find that some furniture animation engines burn way more than others. XPOSE* is an older, notoriously inefficient closed-source system still used in some furniture, and there are probably others, but it may not be worth replacing items scripted with those systems. (There's probably a way to migrate the existing furniture to another animation engine, too. I've done that to a limited extent with MLP and zED configurations migrating to AVsitter—but not for performance reasons, and I never looked at XPOSE.)

Oh, about a rule of thumb for a 1024: This is just so crude I hate to even say it but… regions seem to start having script lag (meaning scripts start delaying each other, not necessarily noticeable to a regular user) when there's more than about 6000 scripts on a normal, non-Homestead region. On one Bellisseria region I count twenty eight 1024s with relatively few scripts outside those parcels (other than those that operate the Mole-built houses themselves), so 6000/28 is a bit over two hundred scripts per 1024. In addition to the caveat that this is very crude, it should also be increasingly obsolete with newer server releases that really are improving script performance.

___________________
*not to be confused with the newer and more performant nPose.

[Lucia Nightfire]

3 hours ago, Qie Niangao said:

I'm not sure there's a handy tool for assessing this (I use an ugly script I hacked myself), but the more important measure is the amount of time spent by an object's scripts, with a secondary measure the script count. (Script memory is an almost totally misleading number as calculated outside the script itself, conveying no actual information beyond count.)

Script count mostly matters because of the way scripts are run, where totally idle scripts burn a little scheduler time just to decide not to run them. And unfortunately, most furniture animation engines including AVsitter contain ridiculously many scripts, partially to hold many animations, and partially out of a misguided "modularity" of features into separate, communicating scripts. But this is a platform-wide problem and there's not much difference an individual landowner can make. I sometimes delete AVsitter scripts for features I know aren't going to be used (faces, for example, is pretty obsolete since mesh heads became ubiquitous), but it won't much matter to sim performance.

Anyway, if you can measure script time of an object you may find that some furniture animation engines burn way more than others. XPOSE* is an older, notoriously inefficient closed-source system still used in some furniture, and there are probably others, but it may not be worth replacing items scripted with those systems. (There's probably a way to migrate the existing furniture to another animation engine, too. I've done that to a limited extent with MLP and zED configurations migrating to AVsitter—but not for performance reasons, and I never looked at XPOSE.)

Oh, about a rule of thumb for a 1024: This is just so crude I hate to even say it but… regions seem to start having script lag (meaning scripts start delaying each other, not necessarily noticeable to a regular user) when there's more than about 6000 scripts on a normal, non-Homestead region. On one Bellisseria region I count twenty eight 1024s with relatively few scripts outside those parcels (other than those that operate the Mole-built houses themselves), so 6000/28 is a bit over two hundred scripts per 1024. In addition to the caveat that this is very crude, it should also be increasingly obsolete with newer server releases that really are improving script performance.

___________________
*not to be confused with the newer and more performant nPose.

XPOSE is no longer common. AVSitter is. The problem in recent years is that retailers keep loading their furniture up with scripts to support various third party applications such as facial expressions, hand poses, various genitals, spunk layers, teledildonics, API scripts for AFK customers, etc. This is on top of optional scripts for texturing, adjustments, props, etc.

It isn't uncommon now to see furniture with 20, 30, 40+ scripts...

[casey Crisp]

Thanks for the very helpful explanation!  It sounds like, from what I gather as a non-techie, that I really have to pay most attention to the total number and time they use (if I can find it).  I was getting more freaked out that when I hit 'script info' on the land tab, some of the kb sizes where almost 1000.

[animats]

4 hours ago, Lucia Nightfire said:

It isn't uncommon now to see furniture with 20, 30, 40+ scripts...

That's excessive. My NPCs have 14, and they're doing a lot. My bikes have 4.

[Prokofy Neva]

On 1/19/2022 at 5:28 AM, Qie Niangao said:

I'm not sure there's a handy tool for assessing this (I use an ugly script I hacked myself), but the more important measure is the amount of time spent by an object's scripts, with a secondary measure the script count. (Script memory is an almost totally misleading number as calculated outside the script itself, conveying no actual information beyond count.)

Script count mostly matters because of the way scripts are run, where totally idle scripts burn a little scheduler time just to decide not to run them. And unfortunately, most furniture animation engines including AVsitter contain ridiculously many scripts, partially to hold many animations, and partially out of a misguided "modularity" of features into separate, communicating scripts. But this is a platform-wide problem and there's not much difference an individual landowner can make. I sometimes delete AVsitter scripts for features I know aren't going to be used (faces, for example, is pretty obsolete since mesh heads became ubiquitous), but it won't much matter to sim performance.

Anyway, if you can measure script time of an object you may find that some furniture animation engines burn way more than others. XPOSE* is an older, notoriously inefficient closed-source system still used in some furniture, and there are probably others, but it may not be worth replacing items scripted with those systems. (There's probably a way to migrate the existing furniture to another animation engine, too. I've done that to a limited extent with MLP and zED configurations migrating to AVsitter—but not for performance reasons, and I never looked at XPOSE.)

Oh, about a rule of thumb for a 1024: This is just so crude I hate to even say it but… regions seem to start having script lag (meaning scripts start delaying each other, not necessarily noticeable to a regular user) when there's more than about 6000 scripts on a normal, non-Homestead region. On one Bellisseria region I count twenty eight 1024s with relatively few scripts outside those parcels (other than those that operate the Mole-built houses themselves), so 6000/28 is a bit over two hundred scripts per 1024. In addition to the caveat that this is very crude, it should also be increasingly obsolete with newer server releases that really are improving script performance.

___________________
*not to be confused with the newer and more performant nPose.

I spend a lot of time on this because people move out of rentals when they feel "your land is laggy" and 5000 is the bar I use. Maybe you have a better computer, but my computer from Best Buy is probably a lot more like those of the average tenant who isn't on Blake Sea or on an island, i.e. in my rentals. I don't see any reason why these rules shouldn't be publicized even if there are caveats. They are generally true. Sure, we all get it that it's not always about the time of this or that script, but their cumulative nature, etc. Still, the sheer number of them, even if they are all low in time, takes its toll.

You can always go through and remove scripts from trees (although if they are the seasonal type, it's a chore to put out new ones instead of just changing their seasons, and they aren't always the culprit). Also many particle things like candles keep working even when the script is removed. You can work for hours though and only free up 300-500 in number so it's really kind of a hopeless cause. And as I already said, if the new performance thing frees up script time all I would do is allow the amount to creep above 5000 or even 7000 because it is not worth trying to police. The Lindens on the regular viewer AFAIK do not have a way to manage script *per parcel*.  Landlords really make themselves unwelcome by going around with script meters and telling tenants to take things into inventory. What I do is use it to police *my own* content that I put out for landscaping etc and may not have realized what hogs they were. And if there is some big bruiser of a problem, an artificial toddler caroming around a house with script times and collisions lagging the sim. I might suggest the tenant put it away when they are not there. No one likes limitations on their content, and this is partly why the Lindens don't get into this business, it's not just the technicalities of making the call on it.

I personally find that if you tamper with furniture with pose scripts, even just to reduce their land impact, or resize them, you run into problems where they cease to work properly and you have to reset or constantly adjust their poses from the default and no one wants to spend time doing that. It's not worth it. And don't assume everyone has a mesh head.

And there is a great free tool by Xoph that shows the scripted items in a list with their times, seems perfectly fine and not ugly.

I also have another radar device that tells you the distance from you and the scripted item so that you can remove it more easily but I think that creator is gone from SL now.

 

[Qie Niangao]

46 minutes ago, Prokofy Neva said:

And as I already said, if the new performance thing frees up script time all I would do is allow the amount to creep above 5000 or even 7000 because it is not worth trying to police.

This is totally anecdotal but on a region (Broadwater) where last week there was substantial script lag (Scripts Run well below 50% constantly) I'm now seeing consistently over 8ms of Spare Time, this with over 10,000 scripts active.

Granted, some of those 10,000 scripts are mine, and other landowners' scripts may have changed in the past week, but still something changed dramatically for the better in how this sim is handling 10,000 scripts.

That script performance blog post didn't give details about what they actually changed so it's an empirical question how generally such improvements will apply. 

About tools, that Xoph item seems useful. Just for variety, here's a script I wrote that also only samples the nearest sixteen scripted objects and reports the one with the very highest script time it finds while I move around and as script times fluctuate (until I touch the containing object to reset that maximum) :

// Report objects with highest script time.
// Touch to reset maximum.
float RANGE = 96.0;
integer SHOW_CREATOR = TRUE;

key maxObject;
float maxTime;

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
        llSensorRepeat("", NULL_KEY, AGENT|SCRIPTED, RANGE, PI, 0.25);
        //llOwnerSay((string)llGetUsedMemory());
        llSetMemoryLimit(15000);
    }
    attach(key id)
    {
        if (NULL_KEY != id)
            llResetScript();
    }
    sensor(integer num_detected)
    {
        while (--num_detected >= 0)
        {
            float thisTime = llList2Float(llGetObjectDetails(llDetectedKey(num_detected), [OBJECT_SCRIPT_TIME]), 0);
            if (thisTime > maxTime)
            {
                maxObject = llDetectedKey(num_detected);
                vector pos = llDetectedPos(num_detected);
                string outStr = "secondlife:///app/objectim/"+(string)maxObject
                    + "?name="+llEscapeURL(llDetectedName(num_detected))
                    + "&owner="+(string)llDetectedOwner(num_detected)
                    + "&slurl="+llGetRegionName()+"/"+(string)pos.x+"/"+(string)pos.y+"/"+(string)pos.z
                    + " : "+(string)(thisTime*1000000)+"μs";
                if (SHOW_CREATOR)
                    outStr += "\nCreated by: secondlife:///app/agent/"
                        +(string)llList2Key(llGetObjectDetails(maxObject,[OBJECT_CREATOR]),0)
                        + "/inspect";
                outStr += "\nOwned by: secondlife:///app/agent/"
                        +(string)llList2Key(llGetObjectDetails(maxObject,[OBJECT_OWNER]),0)
                        + "/inspect";
                llOwnerSay(outStr);
                maxTime = thisTime;
            }
        }
    }
    touch_start(integer num_detected)
    {
        maxTime = 0.0;
    }
    run_time_permissions(integer perms)
    {
        if (PERMISSION_TAKE_CONTROLS & perms)
           llTakeControls(FALSE, FALSE, TRUE);    // Continue running on no-script land
    }
}

The names of the reported objects are clickable which has different levels of usefulness in different viewers, but should make it easier to find the object. As written, it samples four times a second and tends to be pretty spammy, so it's not something to run constantly. (By "ugly" I was more referring to a different script I wrote that can report on specific objects anywhere in the region that the cam observes, but it's too weird and potentially laggy for me to responsibly make public.)