Land/Script Question: Display Total Parcel Script Memory Per Object Owner?

[Ember Ember]

I understand that the function llGetObjectDetails has the ability to get OBJECT_SCRIPT_MEMORY of individual objects. And I am aware that About Land > Script Info shows a list of all objects on a parcel with their individual max/allocated script memory. My question is: is there a way to get the sum total "Memory Used" per Object Owner all added up and displayed in hovertext on a prim?

Currently only the Parcel Owner can view the object list in the Script Info window, but it seems that they would still have to manually add up all the memory to get the total of how much an individual Object Owner is "using". And anyone other than the Parcel Owner is only allowed to see the "Memory used" value in the Script Info window, but it's the total of all objects regardless of object owner. For the Parcel Owner it's convenient to be able to see the list (but would be nicer if totals per object owner were also displayed.) But in the case where I am not the parcel owner, I am searching for a way to see how much memory my rezzed stuff is using up.

The main reason for my question is in the case of multiple parcel users wanting to better manage (and compare) their individual memory use. Thanks in advance for any and all input!

[Quistess Alpha]

Unfortunately, I think that's basically impossible at the moment.

Also, in terms of resource usage, OBJECT_SCRIPT_MEMORY is not a particularly useful metric. IMHO OBJECT_SCRIPT_TIME would be more fair.

[Love Zhaoying]

15 minutes ago, Quistess Alpha said:

in terms of resource usage, OBJECT_SCRIPT_MEMORY is not a particularly useful metric. IMHO OBJECT_SCRIPT_TIME would be more fair.

This makes sense to me. If your scripts use a lot of memory BUT they are not getting any script time (events not firing, etc.) then they should not be penalized.

 

[Quistess Alpha]

4 minutes ago, Love Zhaoying said:

If your scripts use a lot of memory

Not to mention IIRC, OBJECT_SCRIPT_MEMORY doesn't even accurately represent memory usage, just the maximum memory available after llSetMemoryLimit() is taken into account.

[Coffee Pancake]

4 hours ago, Ember Ember said:

The main reason for my question is in the case of multiple parcel users wanting to better manage (and compare) their individual memory use. Thanks in advance for any and all input!

Don't.

Forget script memory or script time are even a thing. It's not worth the time or headache to police and will just be an unnecessary point of contention.

Why?

• Script memory just returns the maximum potential script memory, not the actual script memory. Each script will appear to be 64k in size even with it might only be 12.
• You're chasing KILOBYTES of memory as part of a system with GIGABYTES of memory. That's on par with being concerned your house is a mess, but only obsessively tidying the cutlery drawer (and then yelling at people who touch the forks).
• The SimHost with GIGABYTES of memory is managed by wizards far far away, has many other region processes running on it and all of that is beyond your control. It's not even your problem.
• The other regions on the same SimHost can affect how yours runs. This can look a lot like you have script lag. (you can ask for the region you have land on to be rebooted to a new SimHost via a support ticket)
• The entire scripting engine is designed to lag. On purpose. It's actually fine.
• The more you look at the numbers the more anxiety you get worrying about the numbers, this combined with a script counter is a great way to cause upset, so now you're anxious, miserable and some scripted object is telling you it's all that guys fault (when it's not). Thanks meaningless numbers!
• The meaningless numbers are meaningless as the margin for error is incredibly high. Write a script to benchmark certain scripted actions, see the results fluctuate by upto 30%. Swear loudly (especially if you're updating an objects appearance!)
• This 30% margin for error is why counting the seemingly more useful SCRIPT TIME is a waste of time.
• Unless you track averages and get a decent sample size.
• Which is quite an intensive script .. when the whole point was to ... DAMMIT !

Especially don't !!

• Eject people from the parcel or region if they have high script numbers.
• This is a revolving door that forces the region to do the most intensive action over and over again - loading and unloading an avatar.

Do

• Worry your own scripts using the far more accurate (yet very slow) profiling tools provided. https://wiki.secondlife.com/wiki/LlScriptProfiler

 

If you're worried about per parcel scripts, you're waaaay off in the weeds. The cutlery draw is a mess and the rest of the house can be on fire, but dammit, you're gonna sit here make sure nothing happens to the spoons.

Did you know that scripts can't lag a region anymore (except under specific rare edge cases) and that heavy scripts tend to just cause other scripts to run late. But if your region is lagged for some other reason, then the scripts are where that lag shows first.

The best solution is to shrug. You have scripts, that's great. 

[Ember Ember]

7 hours ago, Coffee Pancake said:

You're chasing KILOBYTES of memory as part of a system with GIGABYTES of memory. That's on par with being concerned your house is a mess, but only obsessively tidying the cutlery drawer (and then yelling at people who touch the forks).

Thank you for the analogy.

[Profaitchikenz Haiku]

17 hours ago, Coffee Pancake said:

Don't.

The more you tell people not to do something, the more they're going to want to try

I agree totally about memory being a chimera, but there are times when somebody arriving in a region with tons of scripted attachments slogged it to a standstill for a second or several. (This might have been fixed last year when they changed the "configuration" though.)

In general I would say to people that the more compact they can make their scripts, the better, and the less time the script requires to do stuff, the better. As such: Any comparative metric is better than none at all. 

Even if it's wrong, it still makes people try to think about the problem instead of just push it under the carpet or blame it on the breedables.

 

Edited April 5, 2023 by Profaitchikenz Haiku

[Qie Niangao]

25 minutes ago, Profaitchikenz Haiku said:

In general I would say to people that the more compact they can make their scripts, the better, and the less time the script requires to do stuff, the better. As such: Any comparative metric is better than none at all. 

In the case of script memory, though, the act of measuring it is more wasteful than the thing being measured—and worse, it may tempt naive scripters to use llSetMemoryLimit which wastes (a tiny bit) more memory just being in the script, inasmuch as its effect is purely cosmetic in almost every application.

Script time has some theoretical validity to the extent that there are so many scripts in the region that they don't all get a chance to run each simulation frame. As already observed, though, it's extraordinarily difficult and time-consuming to get a valid measurement of script time, so just counting the things is often the most practical metric available.

[Ember Ember]

1 hour ago, Profaitchikenz Haiku said:

Any comparative metric is better than none at all. 

I totally agree with this.

[Love Zhaoying]

Part of the problem with using "wrong" metrics, is the temptation to misuse the conclusions.

Just because a script uses more memory, or more script time, should not lead someone to have others at their event / on their region / etc. change their script usage.

I can see utility in changing your OWN script or moderating your OWN script usage, but that's about all, if the metrics are wrong or misleading.

[Coffee Pancake]

10 hours ago, Profaitchikenz Haiku said:

I agree totally about memory being a chimera, but there are times when somebody arriving in a region with tons of scripted attachments slogged it to a standstill for a second or several. (This might have been fixed last year when they changed the "configuration" though.)

This is always going to be a thing, if there was any truth to the idea that having fewer scripts made this less of a bump then vehicle enthusiasts wouldn't still be complaining about region crossings. Loading and unloading an avatar causes a pause. This is entirely normal and why it's a dumb idea to check script counts and eject heavy avatars, especially on regions operating at max population.

Noticing the pause can depend on many factors, some of which might not even be on the Region the new arrival arrived on.

10 hours ago, Profaitchikenz Haiku said:

Any comparative metric is better than none at all. 

If the metric was even self consistent .. and it's not.

I have a script in my house that performs the exact same operation every time its clicked and reports the run time. it can vary between 180 and 500 ms with an almost random quality.

Garbage data is garbage.

10 hours ago, Profaitchikenz Haiku said:

Even if it's wrong, it still makes people try to think about the problem instead of just push it under the carpet or blame it on the breedables.

It makes people think there is a problem that affects their SL, and look, THAT PERSON is the biggest contributor to the "problem".

The "problem" ends up being blown out of all proportion, so rather that it highlighting a lack of region resources and reason to poke Linden support, it becomes a stand in for why everything is wrong with an individuals personal SL.

SL does not have a script memory problem.

If it did, it's not the users problems, that's down to LL in how they allocate server resources. Something they can and do fiddle with whenever the fancy takes them.

[Anna Salyx]

From the Wiki on Mono scripts

Quote

Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. ...  no matter how many copies exist they only take up the size of one script (plus data) in memory.

and what confuses me sometimes, and maybe someone can clarify.

If say 4 people came on to a region and were the only ones there.  And each person is wearing the same given body, and each body has the same script assets. There would be then, if I read above correctly, only one actual instance of the scripts running plus the individual data particulars. 

My point of clarification request: When I do a script count and memory usage for each avatar on the region, each avatar will show their own script count and memory usage and this doesn't take into account script bytecode sharing.  So the sum total amount of scripts and script memory is off by a factor of 3.

• IE it would be like this?  (using round numbers for simplicity)
  • Avatar 1 - 3 scripts, 1 megabyte
  • Avatar 2 - 3 scripts, 1 megabyte
  • Avatar 3 - 3 scripts, 1 megabyte
  • Avatar 4 - 3 scripts, 1 megabyte
  • Total Reported - 12 scripts, 4 megabyte.
  • Total Actual - 3 scripts, 1 megabyte and change.

Do I have the understanding correct that it would be the total actual?

Or would it be closer to the total reported? 

Or would it be somewhere in between?

[Quistess Alpha]

2 hours ago, Anna Salyx said:

Or would it be closer to the total reported? 

Or would it be somewhere in between?

the system doesn't take into account 'bytecode memory' I.E. memory taken up by the actual "script" part of the script. If for sake of argument, we say that those 3 scripts are really beefy and take up half of their available space as bytecode, and assuming the wiki is accurate (we residents can't really know anything about back-end implementation directly) then:

• Avatar 1: .5 meg shared and .5 meg available script memory
• Avatar 2-3: ditto
• 12 scripts, 2 megs available memory, 2 megs shared bytecode /4 = .5 'static memory'.
• 2 + .5 = 2.5 megs total allocated memory.

Of course, the actual memory ~used will be strictly lower than that, depending on how much data the scripts need to store in those 2 megs of 'free space'.

Edited April 6, 2023 by Quistess Alpha

[Ember Ember]

While it is related, it is off topic speaking about an avatar’s worn scripts. I am only asking about rezzed objects on the land like homes, home decor, vehicles etc. Objects that appear in the About Land > Script Info window.

[Anna Salyx]

1 hour ago, Ember Ember said:

While it is related, it is off topic speaking about an avatar’s worn scripts. I am only asking about rezzed objects on the land like homes, home decor, vehicles etc. Objects that appear in the About Land > Script Info window.

I do get that but it is tangentially related.  the omitted part of the wiki quote I used:

Quote

Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script's size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.

The question still raised is how is that being reported.  Is each object and script being reported separately with memory usage by the land counters? If people are rezzing items that do share a same byte code assets, say for example resident A rezes a car, and resident B rezes a different car, but they both use a subset of the same core vehicle scripts, how is that also being reported back?  At the very least, bytecode sharing as described in the wiki certainly muddies the water somewhat on how resources are being used by each resident. I used worn attachments as more simple (at least in my mind) way of raising that and asking the relevant question: Are script/memory counters over inflating the resources being used in some cases?

[Wulfie Reanimator]

3 minutes ago, Anna Salyx said:

Are script/memory counters over inflating the resources being used in some cases?

Yes, they are. Regardless of whether you're looking at llGetObjectDetails or the Script Info window, each object/script will show the maximum amount of memory usable by that instance, regardless of actual usage or sharing.

Edited April 6, 2023 by Wulfie Reanimator

[Love Zhaoying]

1 hour ago, Wulfie Reanimator said:

Yes, they are. Regardless of whether you're looking at llGetObjectDetails or the Script Info window, each object/script will show the maximum amount of memory usable by that instance, regardless of actual usage or sharing.

So..ALL cases!