Jump to content

Script bean counters


Petite Pixie
 Share

You are about to reply to a thread that has been inactive for 4418 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Well it seems to be more and more of an issue. Misinformed and paranoid people putting up script counters and using auto-kick items all based on how many scripts you have in use. Many of them just count scripts inactive or not or how much memory they use. What most of them don't do is actually see what kind of impack you're actrually doing in a sim. I wear my AO and sometimes wings or a weapon and as an ex sim owner I've seen what kind of impact it has on my sim which is usually around 1.2% or less but because there's a lot of scripts (lots of little scripts which are passive as apposed to a huge active script badly written) I am getting told by objects to take off all just to go there. So I leave. Good luck with your sims, I have noticed most of these places are empty....

and lag free..

Link to comment
Share on other sites

Well it's a bit like traffic congestion isn't it.  One person in their one car doesn't think that they are the problem and that it's everyone else in their cars around them that's causing the traffic congestion; who also happen to be thinking the same thing.

Link to comment
Share on other sites

Land owners who use script counters to regulate traffic do so with a view of improving the experience overall for residents who visit.  It is really not difficult to reduce scripts on an avatar and explore or enjoy a destination.  Since most viewers in use enable you to check your own scripts, you can easily adjust.

Their land; their rules.

Link to comment
Share on other sites

Easy to try: Get 50 people on a sim with all their regular scripted junk. Then do the same with 50 people who do not have a single script on them.

Personally I'd be happy if land could be set to no-entry for people with high script memory use. Script count? Meh, not a problem.

Btw, with the script init changes on sim crossings, people with high script count get punished by SL anyway.

Link to comment
Share on other sites

It may help to understand just how limited the options are for measuring the impact of scripts, even after several new functions have been introduced to help.

First, the count of scripts is an important measure, even if the scripts are tiny and idle.  That's because every script that's capable of running (i.e., not set "not running") -- even if it's not doing anything -- slows the sim's execution of other scripts slightly.  That's just how the scheduler works, and it's one of the reasons that good scripters try to use fewer, larger scripts rather than lots of little scripts.

Second, even scripts set to "not running" use memory in the sim, and using too much memory has the potential to crater performance for other, non-script things the sim does, and for every process running on the server, not limited to the single sim using too much memory.

Finally, measuring script memory use is very tricky for a bunch of reasons.  There's one thing in particular that's important but largely misunderstood: the memory reported for a script is not the amount of memory the script is actually using; rather, it's the maximum amount of memory the script can use.  There's a recent addition to the scripting language that lets the scripter set that maximum amount.  Setting this number does not make the script use less memory; it has no benefit to the sim whatsoever. The only purpose it serves is to give external observers a more accurate estimate of the script's actual memory use.

In fact, including the function to set that number itself uses (very slightly) more memory, and may put the script more at risk of breaking should it encounter unexpected conditions.

Link to comment
Share on other sites

This is exactly my complaint Qie.

4 x mono scripts will report as "consuming" 256KB but in fact could be using only 4k for arguments sake.

The quote under llGetObjectDetails states:-

 

  • OBJECT_SCRIPT_MEMORY reports the maximum memory that all scripts in an object could use, not the actual amount of real memory currently used. In particular, Mono scripts only use the amount of memory currently needed, not the max possible. In practice, this makes the number reported a worst case scenario that will never normally be reached by most objects.

So from that yes, that 256KB isn't really 256KB but say 4KB.  On the other hand, make those 4 scripts lsl and that's 64KB.  The worst part is that now the mono rez bug has been dealt with, there's an incentive to recompile to mono and use LESS memory but these retarded and inaccurate measuring details are pressuring people to remain with scripts that are compiled to lsl which report using less but actually could potentially use more.

What to do?  Compile items that lets people wear them where they want but take up more memory in reality but satisfy the Eject-O-Objects or try to educate the owners of the Eject-O-Objects?  If you've tried having an educated conversation with them, you'll understand which of these options to take.

 

Link to comment
Share on other sites

Sort of...

https://jira.secondlife.com/browse/SVC-5497

It explains why at this point in time there's no way to accurately count script memory use.

For me the bottom line is relatively simple: Some people are flat out sim memory hogs. I care little about script throttling, there's nothing on my land that needs to run realtime. There's zero reason to have 100+ scripts on an avi. All that shows is that some scripter has absolutely no clue what they're doing. For that, it's entirely irrelevant whether or not the scripts are running or stopped. They still consume sim memory.

The good thing is also that peopl who DO carry around a lot of scripts do get penalized on region crossings (and teleports). Their scripts will get a fairly high delay until they continue operating on the new region. From a post by Kelly Linden:

"Mono scripts are loaded more slowly. We now lazily load Mono scripts
that are added to the region. If your object has a single script that
script will load and start immediately. However, if you have
100 scripts it will take about a second for all scripts to fully load
and start. Technical Details: we start Mono scripts at a rate of up to 3 per
simulator frame or a max of 135 per second. This spreads the simulator load out
over time so that the simulator performance is not impacted when
objects with lots of Mono scripts are added to the region"

Link to comment
Share on other sites

It's not something that you "fix" easily.  As Qie and Sassy said, a MONO script reserves 64K of memory for use (unless you limit it with one of the new functions), even if it only actually uses half of that or less.  Many scripts do use way less than the maximum, in fact, but it's not easy to tell how much less.  If you use one of the new functions to reduce the allowable amount and guess wrong, the script will freeze up.  So, even if scripters start cutting back from 64K per script, their scripts will still always include a certain amount of reserved but unused memory.  That counts against the sim's total.

To my mind, though, memory isn't the real challenge anyway.  It's script time, and that's almost independent of the number of scripts you have running and the memory that they use.  A sim that is using more than about 20ms of total script time has a pretty heavy usage pattern.  An individual avatar in that sim might account for 0.02ms of that total or more.  (I have 8 scripts running on me right now, for a total of 0.011ms. )  The av's total script time could be much higher if she is (1) wearing a ton of scripts or (2) wearing only a few scripts that use a load of script time.   A single very busy AO or a fast-firing radar will make much more difference to a sim than a handful of size-changing scripts in someone's hair.

Link to comment
Share on other sites

Scripts do get throttled first, but if it's your scripts that get throttled, and if scripts on the sim as a whole start lagging or freezing........

Just saying.....  the number of scripts you carry is the least of the things you should be concerned about.  Total script memory and script time are more important by far.  Unfortunately, it's a lot easier to measure numbers of scripts.

Link to comment
Share on other sites

Exactly. Hence the nagging of people who simply cart around insane amounts of scripts. That scripts make a difference is something I've experienced quite a few times. I've been in venues where 40 people brought the sim to a screeching halt. And I've taught at a school where the rule was "no scripts" even back then. That school did occasionally have a full sim with 100 people - and (nearly) no lag.

Link to comment
Share on other sites

another factor is that if script time is high, causing script throttling, that effect is deadly for vehicles, and some physics applications. but if memory is high enough it can still cause paging. paging sucks the life out of a whole region.

there's lots of room to play in the current model though, and 10MiB isn't that uncommon, nor is it usually that much of a negative impact... anything over that is patently absurd IMO, and a target of under 2MiB is preferable, and easly achievable for most users (that 32 mono scripts at full capacity). anyone that even mentions something about THAT low level  of usage out of the blue should probably be smacked with a clue stick.

Link to comment
Share on other sites

I have a script counter on my sim (wich inform about scripts running and memory used by avi) . The reason? i got tired to hear people running with more than 500 scripts and complaining about lag on the region...Some people need seriously consider how their high script count may  ruin  the experience of others instead be offended by script counters...

Link to comment
Share on other sites

  • 3 months later...
You are about to reply to a thread that has been inactive for 4418 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...