Q Lag monitors, memory use and mono scripts

[Kwakkelde Kwak]

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).

So my question is:

Are the scripts reading the memory use poorly written or is it just a poor script command? Or am I overlooking something?

Any information on the subject is welcome...

[Lucinda Bulloch]

removed

[Kwakkelde Kwak]

Yes for a proper monitoring I wouldn't rely on such a device, although it can be helpful. The thing is some people rezz these things in their store and the thing will show the numbers it reads together with the avatars name. So in many cases I am wrongfully flagged as laggy. Or at least I am pretty sure it is wrongfully. I always check my things before buying if possible and if not, I check after, both scripttimes and rendercosts. I have dismissed many items even though I really liked their looks or functions. Sometimes I use laggy items, but I try to keep it to a minimum, especially when going shopping...

[Lucinda Bulloch]

removed

[Kwakkelde Kwak]

I know I know:) I'm not that worried about lag, well not lag produced by me anyway. I am slightly worried though by being flagged as laggy even when I am not.

Some avatars can be extremely scriptlaggy though, I've seen constant readings of 5.0 ms on a single avatar, that DOES worry me.

So what I am really interested in is if these meters are useless when it comes to memoryreadings on monoscripts..

[Qie Niangao]

They're only mostly useless. :matte-motes-silly:

I'm not sure you're aware of the llSetMemoryLimit() function for Mono scripts.  While that function does nothing to reduce the actual memory consumption (and uses some negligible amount of memory itself), it does reduce the amount of memory the script is shown to be using.  Of course, it will also cause the script to blow up if it exceeds the set limiit, but that's sort of the point.  Anyway, if your Mono scripts are really low memory use, you can "prove" it using that function, and maybe avoid the script sinner label.

[Kwakkelde Kwak]

 

---

Qie Niangao wrote:

I'm not sure you're aware of the

llSetMemoryLimit()

function for Mono scripts.  While that function does nothing to reduce the actual memory consumption (and uses some negligible amount of memory itself), it does reduce the amount of memory the script is shown to be using.

---

I suspected that, but the creator (rightfully I think) refuses to add that code to the scripts since it only adds to the scriptload, even though the readings on it will show otherwise... anyway, thanks for confirming this.

EDIT: Now this is a question for my own scripts... I was wondering if a mono script limited to 16k (or 15.9 for balancing out the function itself ) is always preferred over an LSL script.

[PeterCanessa Oh]

---

Lucinda Bulloch wrote:

...Try to ignore the macho game of the script writers most have an axe to grind.

---

 

Ah yes, that's the thing to do, of course!  If you ignore the people who know what they're talking about then there's no problem.  As long as you don't feel ill what does it matter that the doctor says you have typhoid?  Only other people die after all, and you clearly don't care about them.  Thank you so much for putting my mind at rest.

@OP - memory use is not a great indicator of lag.  A small, very busy, script could make a sim work harder than a large one that isn't doing very much at the moment.  There is a major problem, however, when the total memory in use exceeds that available for the sim.  If that happens the servers have to use virtual memory, which is much much slower, and several sims start to grind to a halt.  It was for that reason that LL introduced the idea (since shelved) of script limits and started to give us the functionality to monitor script usage.  Scripts compiled in LSO are always assigned 16k, scripts compiled in MONO are always assigned 64k unless it requests a lower limit (llSetMemoryLimit()).  You might not normally feel any lag from your scripts but every TP/sim crossing will be slower with them and will affect everyone in the new sim.  Should you be the one to tip the server over to virtual memory then you'll feel it and so will everyone in all the sims that server handles.  Having very active scripts that are actually using a lot of processing time is a different issue.  Simply put if all the script-time is consumed in a sim then other scripts in that sim will be lagged.

llSetMemoryLimit() is a single function - it might add a few bytes to the code once but it can save the server (and your blushes) many thousands - the only sense in NOT using it is if your scripts are likely to be using something near 64k anyway.  There are still slight issues with MONO script instantiation on sim-entry but other than that I think one set at 16k (or lower) would be preferable in all cases.

[Kelly Linden]

---

Kwakkelde Kwak wrote:

 

---

Qie Niangao wrote:

 

I'm not sure you're aware of the

llSetMemoryLimit()

function for Mono scripts.  While that function does nothing to reduce the actual memory consumption (and uses some negligible amount of memory itself), it does reduce the amount of memory the script is shown to be using.

---

 

I suspected that, but the creator (rightfully I think) refuses to add that code to the scripts since it only adds to the scriptload, even though the readings on it will show otherwise... anyway, thanks for confirming this.

 

---

llSetMemoryLimit does not add to the script load in any meaningful way, if called once (in state_entry) and left. If you constantly monitor and adjust it, then doing that may have some load consequences depending on how it is done.

All mono scripts already have a 'max_memory' that defaults to 64k. llSetMemoryLimit allows the script to tweak that number. That is all it does. If done once it will have no additional script impact after being called.

llSetMemoryLimit right now is intended specifically for this case, to allow scripts to "prove" they are low memory use. Don't let superstition stop that.

[Kwakkelde Kwak]

Ok, thank you all for answering...

I'll change my LSL scripts to mono then (with a limit) and see what happens.

The original question really wasn't for my own scripts, but I'll poke the creator once more:)

[Kwakkelde Kwak]

---

PeterCanessa Oh wrote:

Scripts compiled in LSO are always assigned 16k, scripts compiled in MONO are always assigned 64k unless it requests a lower limit (llSetMemoryLimit()).

---

As far as i know the LSO scripts are assigned 16k and mono scripts are assigned 0-64k, not 64k. True or false?

[PeterCanessa Oh]

False according to the wiki "All new [MONO] scripts start with a limit of 64k" http://wiki.secondlife.com/wiki/LlSetMemoryLimit

[Kwakkelde Kwak]

I'd say true then...

The memory limit is not the amount of real memory actually used by the script, just the upper limit on it.

thanks for linking that ...

[Qie Niangao]

Right, but that 64K limit is only an accounting reservation -- it is not mapped.  Only the memory actually used by Mono gets allocated.  Using llSetMemoryLimit() changes that accounting reservation, but doesn't reduce the actual memory use.

It's still a good thing to do, particularly for attachments, specifically for the reason confronting the OP.

[PeterCanessa Oh]

Yes - the script may only be using a few bytes but the important thing is that the server reserves 64k for it, even if it doesn't need to.  So false - 64k is reserved for each and every MONO script, just in case it uses it 'at some point'.  Even setting a lower limit the script will, presumably (Kelly can verify if it's worth it), get 64k initially, then the llSetMemoryLimit() releases some back to the server.

[Kwakkelde Kwak]

Ok, I'm getting confused now:)

 

Hypothetical, if the memory of a sim is 128k...

you can run 8 LSO scripts on it without the virtual memory being adressed, that's clear.

but what happens if you run monoscripts using 4k each? Can you run 16 of them or 2 before things crawl to a halt?

I'm not that educated on scripting, but common sense tells me the 4k of each mono script goes in the RAM. Then even if those script have 60k reserved, that reservation will not chip away from the RAM available. This would mean you can run 16 of them without using any virtual memory.

[Lucinda Bulloch]

removed

[Kwakkelde Kwak]

Script limits as proposed in the past (as far as I know) have got nothing to do with this. Those limits would be per avatar or per sqm or parcel or something. Not per script. The scripts already have a limit, 16k and 64k.

So what you are saying is you can only use 2 mono scripts on that hypothetical 128k sim/core? I find that very hard to believe really.

[Kelly Linden]

---

PeterCanessa Oh wrote:

Yes - the script may only be

using

a few bytes but

the important thing is that the server reserves 64k for it, even if it doesn't need to

.  So false - 64k is reserved for each and every MONO script, just in case it uses it 'at some point'.  Even setting a lower limit the script will, presumably (Kelly can verify if it's worth it), get 64k initially, then the llSetMemoryLimit() releases some back to the server.

---

This is incorrect. Scripts compiled to mono only actually use they memory they need. They default to being allowed to use up to 64k. llSetMemoryLimit can change that value to something lower than 64k. However since we allow the script to use up to this setting we consider that the 'reserved' amount for accounting purposes. Another way to think about it is that the script is guaranteed to be able to use up to 64k by default. So for *accounting purposes* the script 'reserves' 64k but will only allocate and use what it needs.

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.

[Kelly Linden]

---

Lucinda Bulloch wrote:

As Mr. linden said it will still take up 64k, once upon a time they were going to have script limits, they did a lot of work for it, created new instructions, then they found out that if they implemented them things like DCS would not work with all its magic and web sites, so they stopped, now in the very start of this I warned you of the macho game, seems within a few post you got caught in that trap.

 

Don't worry to much, when it all came out in the first place I made detectors adjusted all my script then found out it wasn't going to happen. lol, but the script snobs still love to make an issue out of nothing.

---

This is not a version of history that I remember. Some work was done towards memory limits, and it is still something we may possibly implement in the future. llSetMemoryLimit is indeed one piece along that road.

[PeterCanessa Oh]

---

Kelly Linden wrote:

This is incorrect. Scripts compiled to mono only actually use they memory they need. They default to being allowed to use up to 64k. llSetMemoryLimit can change that value to something lower than 64k....

---

 

Thanks for the clarification Kelly.

@OP - so it's running as it 'should'; only what's used is allocated so you could run 32 MONO scripts in that hypothetical 128k if they were all tiny :-)  That also means that the lag detectors you were originally asking about are going to be fairly useful as long as people start using llSetMemoryLimit() to make the 'accounting purposes' as accurate as possible.  Fair enough; for failing to file proper accounts we'll be "charged" 64k.  Good egotistical scripters with sharp axes and sharper code will be recognised with a lower memory-cost shown by those detectors.

[Kwakkelde Kwak]

As long as...hehe..yes.

Well either way it might be good practice to use the limit anyway, as Kelly said, it's a next step towards script limits and I'm sure that limiter will use the same numbers as the current monitors...

Some things confirmed, some things learned...not a bad thread for me!

[Qie Niangao]

I might add just one thing.  At some point there was a question about whether there's ever any reason to use LSL-compiled scripts, and there's a narrow edge case* where it's a win.  

The reason is that Mono-compiled scripts almost always use appreciably more memory to represent data than they'd require if compiled under LSL.  That's especially true of strings, but it's also true for other data structures.  More often than not, this doesn't matter: most scripts fit under 16KB whether compiled as LSL or Mono.  But LSL-compiled scripts that are close to the 16KB limit will almost always require more than 16KB when Mono-compiled.  The performance advantage may be worth the extra memory overhead, but it's a consideration -- and can motivate design changes when migrating a large system from LSL- to Mono-compilation.

__________

*That's in addition to any remaining extra overhead of instantiating a Mono script on a sim, as Peter mentioned, which I suspect is unavoidable but now negligible.

[Kwakkelde Kwak]

Thanks for that, it actually rings a very small bell yes...

I'll keep that in mind in case a 16k mono script gets errors....

[Rufus Darkfold]

I built a multifunction HUD,  and I keep the functions I'm not currently using disabled to avoid bugs and lag from all those event handlers getting called needlessly, and possibly to reduce the sim-crossing lag (since disabled functions' state is not passed to the new sim).

It would be nice to have a disable-and-reset function that would allow a script to reset and disable itself at the same time, so it frees whatever memory it can and doesn't use any more until it is re-enabled.

In its absence,  would this sort of thing be helpful?

biglist = [];   // we can't make it go away, but we can at least make it smallerbigstring = ""; // ditto,, repeat for any large strings or lists.llSetMemoryLimit(llGetUsedMemory());llSetScriptState(llGetScriptName(), FALSE);llResetScript();  // come here when we get re-enabled.  (unless we did a sim crossing, then we reset anyway)