Question about a type of HUD

[Phil Deakins]

In a recent thread, somone posted that it's possible know how much memory an object uses for its scripts before buying it. It was stated that a HUD is needed and someone sent one to me. I don't accept objects from people I don't know so I'd deleted it before reading in the thread that she'd sent it. But I have a question about these HUDs...

With Phoenix, and presumably with their other viewer, you can right click on an object, click More>, More> and then S. Count, and it will tell you how many scripts are in the objects, the size of the scripts, and the time of them. What I'd like to know is whether or not those HUDs provide the same size information.

The reason I ask is because the number that Phoenix shows is wrong. All it does is add up the maximum filesizes of the scripts. So 16k is added for a tiny script that actually uses, say, 1k of memory, if it's compiled with LSO. Similarly, if it's compiled with Mono, 64k will be added, even though it only uses 1k of memory. Consequently, the total reported is no reflection at all on the actual total memory the scripts use and is, therefore, a waste of time showing it.

If the HUDs show an accurate number, and don't do what Phoenix does, then I'd like to get hold of one.

[PeterCanessa Oh]

Nothing can track the maximum script-time something may use.  Each LSO script may use a maximum of 16k, each Mono script a maximum of 64k.  All the rest depends on how well the HUD is scripted and, for that matter, how well and newly-scripted the object in question is.

http://wiki.secondlife.com/wiki/LlSetMemoryLimit is very new.  Before this EVERY script ALWAYS counted as 16k (LSO) or 64k (Mono).  Using llSetMemoryLimit() a good scripter can announce to the world that their Mono script only requires 4k, or whatever, AT THE MOMENT.  At any point that script might think 'to hell with it, I'm going to go wild and party', request the full 64k and fill it all.

http://wiki.secondlife.com/wiki/LlGetObjectDetails with OBJECT_SCRIPT_TIME will, similarly, tell you how much time the script has taken to process during the last 20 minutes.  While it's sat there idle that could be very low.  When the party starts, or an error happens, it could lag your sim to death. No way of telling.

Neither of these addresses how you'd check objects that aren't rezzed, of course.  Nearly everything for sale is in a vendor or on marketplace.

[Phil Deakins]

It's not the script time that I'm after, Peter. It's the amount of memory the scripts in an object use.

Incidentally, I'm reliably informed (by Qie) that setting a script's memory limit is irrelevant, and only any good for reporting. A Mono script can use up to 64k but it only uses the amount of memory that it actually needs, so setting the memory limit makes no difference, except for reporting.

[PeterCanessa Oh]

Phil, you mentioned "how many scripts are in the objects, the size of the scripts, and the time of them" and it's all the same reporting function (llGetObjectDetails) so I told you size and time.

Setting a script's memory is only good for reporting, but that's what gets reported so it's pretty relevant when you ask about what's reported ^^

As I said, any time a script can just grab the maximum its allowed, so any less that is ever reported is pretty immaterial.  If, however, you are asking about exactly how much a script is using right now, that's http://wiki.secondlife.com/wiki/LlGetUsedMemory but you can't check it on another object (and LSO scripts always count 16k anyway)

[Phil Deakins]

I know about llGet Used memory() Peter. In fact I use it. I'm asking about a HUD that was mentioned in a recent thread and I want to know if it can report the correct memory useage on any scripted object rather that the simple (but incorrect) sum of max sizes.that is reported by Phoenix. I specifically want to know what the HUD reports.

[PeterCanessa Oh]

You're winding me up aren't you?  Especially as Qie will already have told you.  A HUD will report what it's been told to report by the script being reported.  llGetObjectDetails() reports the sum of the memory reports for the scripts that use llSetMemoryLimit(), 64k for any Mono script that doesn't and 16k for every LSO script.  The actual report reports the reporting figure and not the actual figure.  What's hard about that?

(That does make sense but, as we both know, not necessarily in the right order)

[Jenni Darkwatch]

I think I was the one who sent the HUD to you. If you want I'll re-send it. It's free, it's full-perm and I made it myself What it provides is the script count, script mem, script time use (as already explained in more detail by others in this thread). None of these values are 100% accurate simply because of how scripts work in SL. They are, however, a fairly good indicator on who's the biggest moron in a busy venue.

If you like I'll re-send it again. Since it's fullperm you can look at the script and see what it does and how it works. And of course you can modify it, sell it or do whatever you like with it without even needing to give credit, including claiming you wrote it

[Phil Deakins]

I'm not winding youup at all, Peter. If you read my first post again - slowly  - you'll see what I'm wanting to know.

[Phil Deakins]

Thank you, Jenni. I'd appreciate a resend

In the other thread, I'd already not accepted the HUD before you posted that you'd sent it, and I was too embarrassed to say so at the time.

It was Qie who posted in that thread that we can see how much script memory an object uses before we buy it these days. But, if we can't get any more accurate than the sum of all maximums, we can't see how much memory an object uses at all. That's what I'm trying to find out - waht exactly these HUDs show.

[PeterCanessa Oh]

Nah, you're 'aving a laugh mate.  I'm not typing it a fourth time.  Read llSetMemoryLimit() and decide for yourself.

[Phil Deakins]

The problem with that is that you're saying there is no way of getting the more accurate script memory useage of an object unless the scripter has set the memory limit, and even then it would be set higher than is actually used. So you're saying that HUDs can't do it, but not in so many words. And yet Qie said it's possible, so my question about that type of HUD is still open.

I see in my emails that Jenni has sent me her HUD so I'll be able to see for myself

The reason I'm asking is because Phoenix reports one of my objects (one I'm currently working on) as using 192k  of memory (3 mono scripts) and if people actually believe that, they will have been grossly misled because it actually uses less than a third of that. If the HUDs can't do any better, then it would be bad for people to think they can tell how much script memory an object uses before buying it, especially if they judge an object's impact by it.

[Phil Deakins]

Ok. I think I have my answer (unless Qie was thinking of another method). The script memory information that Phoenix and Jenni's HUD return are the maximum that *might* be used by an object - the maximum that an object is able to use whether it gets close to using it or not. Pity.

[Jenni Darkwatch]

Unfortunately that's correct, at least for mono scripts. LSO always uses the full amount, as said before.

If you think about it, you can see why that's the case: Mono allocates memory on demand, just like any other modern programming language. Therefore, it's impossible to actually know how much memory a script is using except as a snapshot in time.

Good practice for scripting should be to set the scripts memory limit within the script, precisely because people can now see script memory use. Though personally, script count would be more important for anything on an avi, since mono script status gets initialized on a delayed timer when teleporting or sim crossing.

[Phil Deakins]

I was hoping that Qie was referring to another way than just the sum of max possible amounts.

Unfortunately, most script memory useage is misleading but I'll set the memory required, if only to check that Phoenix reports it correctly, as it makes no difference to a script's actual useage.

Thank you for your help, Jenni. It's appreciated.

[PeterCanessa Oh]

Yep, that's it.  I knew you knew that really.

Except.  My llSetMemoryLimit(4096) Mono script will report as a 4k script, behave as a 4k script and be a 4k script only as long as it isn't at a party.  As soon as it is it just says llSetMemoryLimit(65536), switches from llWhisper() to llShout() and goes wild.

So even if a script uses low memory and is set to report low memory at the moment you have no way to tell what its future behaviour will be like.

[Phil Deakins]

lol. No I didn't know. I did know that a new thing that LL introduced a while back only showed the sum of maximums, and I thought that was rather useless. It was obvious that what Phoenix shows is also the sum of maximums. But when Qie said in a recent thread that customers can now see how much memory an object uses before buying, I thought it was something different that would actually show the correct value, which is why I started this thread. I wanted to know, and now I do - there is no way for a customer to know how much memory an object's scripts use before buying.

Anyway, just for the sake of it, rather than for any practical value, I now have the memory limit of each of the 4 mono scripts in the object I'm working on set to a little above what they are actually using after initialising, and the object now shoes 75k instead of the sum of maximums (256k) that it showed previously.

[Phil Deakins]

---

PeterCanessa Oh wrote:

Yep, that's it.  I knew you knew that really.

Except.  My llSetMemoryLimit(4096) Mono script will report as a 4k script, behave as a 4k script and

be

 a 4k script only as long as it isn't at a party.  As soon as it is it just says

llSetMemoryLimit(65536)

, switches from llWhisper() to llShout() and goes wild.

---

Shouldn't that be 65535? There are 65536 bytes in 64k but the numbering is 0-based

[PeterCanessa Oh]

Lol, I have no idea what happens if you specify a number over 64k to be honest.  It may ignore it, set maximum, error or cause the spontaneous creation of dancing woozles.

[Qie Niangao]

Eep.  I think I caused some confusion here with something I expressed too informally. Sorry for not seeing this and clarifying sooner.  All such scripts (and viewers) can see is the current setting of maximum memory the script is claiming it might use, not what it's actually currently using.

As already mentioned, the script itself can see how much it's really using at the moment, but that's said to be a very expensive function call.

I would just reiterate that even those current maximums are only current maximums. A script can ask to change that limit at any time. And of course any instantaneous measurement of script time may be unrepresentative of the object's demands under different circumstances.  For that matter, in objects consisting of more than one prim, even the active script count can change under script control.

[Phil Deakins]

When setting a limit that's over 64k, I believe it quietly sets it to 64k. If I'd written that bit of the system, I'd have sent the owner "cheeky buggar" message and set it to only 4k, and laugh while I imagine them trying to figure out why they can't get rid of the stack-heap collisions

[Phil Deakins]

Qie! Welcome to the thread

I was trying to clarify what I remembered of what you wrote - out of curiosity more than anything. And I managed it. Thank you for confirming what I've now understood.

[Perrie Juran]

Having read through this I hope I am not being redundant by asking this, but want to be sure I am understanding what is being said here.

All these so called 'script counters' are not reporting actual usage but the potential maximum that all the scripts I am 'wearing' might use?

[PeterCanessa Oh]

(I'm going to get you at play-time for making me do this again)

By default: Every LSO script is reported as 16k, every Mono script as 64k

Old script-counters just asked an object/avatar how many scripts they had:

• They will report (LSO count * 16k) + (Mono count * 64k)

'Better' scipt-memory devices will ask an object/avatar how much to report for its scripts.  For each script:

• If it is compiled to LSO it is always reported as 16k
• If it is compiled to Mono it is reported as 64k UNLESS its scripter used llSetMemoryLimit()
• If it is compiled to Mono and its scripter used llSetMemoryLimit() it is reported as whatever the current limit is (<= 64k)

Even if a scripter has used llSetMemoryLimit() that is only:

• a declared maximum that can be changed at any time
• almost certainly not what is actually being used at any particular moment

There is no way for any script to find out how much memory another script is actually using but, even if there were, it would be pointless because an apparently low-memory script can suddenly declare and use up to 16k/64k at any moment, should it be written that way.  The best/most honest use for llSetMemoryLimit() is for a scripter to use it once in each script as a way of announcing 'the script will never use more than this', but there's no way to check if that is what they've done or not.

[Frighteningly enough calculations to check the performance/memory/profile of programs are themselves 'uncomputable' and have been discussed since Babbage's time.  It comes down to "the only way you can tell what a program will do is to run the program and find out".]

[Perrie Juran]

---

PeterCanessa Oh wrote:

(

I'm going to get you at play-time for making me do this again

)

---

Thank you and my apology for disturbing your play time.

I've got a habit of looking for the least common denominator and sometimes it still turns out to be complex.