Memory Usage - from the Wiki

[Fenix Eldritch]

That doesn't even make sense. You're arguing that:

9 hours ago, steph Arnott said:

If you insert the key of the group as a string I.E "0000........................" it will throw up an unsupported error at runtime. So that indicates that the key is recorded in a industry standard format but changed for whatever reason when copied as a string.

Which over the course of this thread, we've proved that statement is not true.

Then you claim that it only happens some times and provide flawed examples that turn out to be user error. The key you provide is a valid one for your own group. The implication being that this valid key would be able to cause the error - otherwise why use it?

Then you claim that the corrected example still exhibits the problem. But refuse to show that code or what key you used

Then you claim that you

1 hour ago, steph Arnott said:

just tryed six group keys, two work, four do not.

But again, you don't show the code, nor the keys used. You expect us to just take your word for it.

Then you claim that another nameless scripter also has the same problem - again with absolutely no proof or references to corroborate what you say, just your word alone.

If you want us to take you seriously, you have to provide something tangential we can work with. Otherwise, it's just baseless claims.

Again if you have keys that you know to cause the error, share them with use so we can see the problem manifest in real time.

Edited March 22, 2019 by Fenix Eldritch

[steph Arnott]

Just now, Fenix Eldritch said:

That doesn't even make sense. You're arguing that:

Which over the course of this thread, we've proved that statement is not true.

Then you claim that it only happens some times and provide flawed examples that turn out to be user error. The key you provide is a valid one for your own group. The implication being that this valid key would be able to cause the error - otherwise why use it?

Then you claim that the corrected example still exhibits the problem. But refuse to show that code or what key you used

Then you claim that you

But again, you don't show the code, nor the keys used. You expect us to just take your word for it.

Then you claim that another nameless scripter also has the same problem - again with absolutely no proof or references to corroborate what you say, just your word alone.

If you want us to take you seriously, you have to provide something tangential we can work with. Otherwise, it's just baseless claims.

This conversation is deceased. The way i do it is correct, the other can cause issues. That is all i care about. I politely listened to five mins of techno babble which ended in my freind saying that LL should be using upto date code language in tandom rather than one anachronistic kludge that is still used. Good day.

[Fenix Eldritch]

I'm assuming "your" way is the method of breaking up the SLurl into thee parts:

• "secondlife:///app/group/"
• key variable holding the group, cast to string
• "/about"

And that the "other" way is by pasting in the raw key as string text instead of being contained in a variable, correct?

Both ways work. But that's not the issue here. You claimed that if you replace the middle variable with the key value pasted in, you'd get an error with the SLurl. But the examples posted previously clearly show that doing the "other" way does work.

What of those four keys you said you tested but did not work? Share them. I'm very curious to see how this supposed failure happens. Are you absolutely sure those keys are for group keys?

[steph Arnott]

2 hours ago, Fenix Eldritch said:

I'm assuming "your" way is the method of breaking up the SLurl into thee parts:

• "secondlife:///app/group/"
• key variable holding the group, cast to string
• "/about"

And that the "other" way is by pasting in the raw key as string text instead of being contained in a variable, correct?

Both ways work. But that's not the issue here. You claimed that if you replace the middle variable with the key value pasted in, you'd get an error with the SLurl. But the examples posted previously clearly show that doing the "other" way does work.

What of those four keys you said you tested but did not work? Share them. I'm very curious to see how this supposed failure happens. Are you absolutely sure those keys are for group keys?

More than i have had an issue. Best you do your way, we do our way.

[Wulfie Reanimator]

I have never been in this much pain from just reading.

[steph Arnott]

8 hours ago, Wulfie Reanimator said:

I have never been in this much pain from just reading.

Do not read if it is affecting you. May be you  stick pins in your eyeballs and complain it is painfull as well.

[Fenix Eldritch]

How disappointing. After going to such great lengths to avoid demonstrating the problem you claim to have, I am left wondering if you were just making it up, or trying to save face after some other user error. Oh well. You do you, I guess.

[Love Zhaoying]

I think we would help if we were given more information. That seems to be the consensus.

[Love Zhaoying]

On 3/22/2019 at 6:19 AM, steph Arnott said:

 

On 3/22/2019 at 6:10 AM, Wandering Soulstar said:

Actually Steph, as it states above, it does reduce the the memory used, i.e. smaller byte code. In the Wiki as well, under the definition of Float:

What's more ... when the script is 'run' as you state, it has already been compiled and the 'conversion' completed, at run time just executing the byte code. Finally .. would be interested in understanding what issues you are referring to .. have not seen any reference to this before.

It reduces static bytes, not less memory.

 

What’s a “static byte”? Programmer here.

[Fenix Eldritch]

I presume they're referring to the size of the bytecode of the compiled script. The bytecode doesn't change unless you recompile the script. Less bytecode means you have more space available for the stack (working memory of the script during execution).

[Love Zhaoying]

1 minute ago, Fenix Eldritch said:

I presume they're referring to the size of the bytecode of the compiled script. The bytecode doesn't change unless you recompile the script. Less bytecode means you have more space available for the stack (working memory of the script during execution).

I had a script awhile back that across different revisions had less and less memory free, unexplainably. I finally copied the source to a “new script”, and it magically had a lot more memory free. (No, I didn’t have “Mono” unchecked by accident.) Based on that experience, I am willing to believe almost anything is possible.

[Fenix Eldritch]

That's indeed very odd. Out of curiosity, how were you determining that you had progressively less memory? Perhaps there were bugs with the functions used to report the available memory at the time? I found at least one old issue on the JIRA where llGetFreeMemory would report negative values. I suppose it's not impossible that you could have stumbled upon something like that and had it fixed? I dunno, it's complete conjecture on my part.

[steph Arnott]

42 minutes ago, Love Zhaoying said:

What’s a “static byte”? Programmer here.

I just meant something that does not change. I was tired and could not think of an English word that siuted.

[Nova Convair]

8 hours ago, Love Zhaoying said:

I had a script awhile back that across different revisions had less and less memory free, unexplainably. I finally copied the source to a “new script”, and it magically had a lot more memory free. (No, I didn’t have “Mono” unchecked by accident.) Based on that experience, I am willing to believe almost anything is possible.

llGetFreeMemory doesn't show you the whole free memory. If your memory gets fragmented there will be holes = chunks of unused memory. That happens always if a script allocates and frees blocks of different sized memory for global variables. (so if you can - use local variables - when the function or eventhandler ends - the stack is set back and therefore all memory is freed)

I don't know if Mono allocates from the holes or not (I think it doesn't) but since it will not always match you will loose memory over time. The garbage collection will do a cleanup and makes all unused memory available.

Question is when does mono run a garbage collection on a script? Since that uses alot of resources that will happen very rare. By my observations that happens when the script occupies over 64k. For small scripts it may happens after quite a while or maybe never as long as 64k is not exceeded.

I'd expect that a reset cleans up everything though. If that is not the case - well - it's SL :D

[steph Arnott]

8 minutes ago, Nova Convair said:

Question is when does mono run a garbage collection on a script? Since that uses alot of resources that will happen very rare. By my observations that happens when the script occupies over 64k. For small scripts it may happens after quite a while or maybe never as long as 64k is not exceeded.

It does not as far as i can gather. An in progress script should be kept for editing and the code pasted to a virgin script or preferably to an external editor. Edited scripts seem to retain the crud. Scripts can become so corrupted with heavy editing that you can get odd things happening or it can even stop working.

[Qie Niangao]

20 minutes ago, Nova Convair said:

Question is when does mono run a garbage collection on a script?

It can be forced with llSetMemoryLimit().

AFAIK it's undocumented and non-obvious, but I found it worked when I desperately needed it for an application that was profligate in allocating and freeing memory, and really needed to know how much memory it had available to allocate.

In fact it may be the sole practical use I've ever found for llSetMemoryLimit().

[steph Arnott]

2 hours ago, Qie Niangao said:

 

In fact it may be the sole practical use I've ever found for llSetMemoryLimit().

If you use it correctly the script will only use what is set else it will stack-heap Collide. Run this and it will crash at count 23. This repeated assertion that scripts with a memory limit  cap does not do anything is nonsense.

Quote

list test;
default
{
    state_entry()
    {
        llSetMemoryLimit(llRound(llGetUsedMemory( ) * 1.10) );
    }
    touch_start(integer n)
    {
        while (1) {
            test += 1; 
            llSetText((string)llGetListLength(test),<1.0,1.0,1.0>,1.0);
        }
    }
}

 

 

Edited March 24, 2019 by steph Arnott

[Love Zhaoying]

9 hours ago, Nova Convair said:

llGetFreeMemory doesn't show you the whole free memory. If your memory gets fragmented there will be holes = chunks of unused memory. That happens always if a script allocates and frees blocks of different sized memory for global variables. (so if you can - use local variables - when the function or eventhandler ends - the stack is set back and therefore all memory is freed)

I don't know if Mono allocates from the holes or not (I think it doesn't) but since it will not always match you will loose memory over time. The garbage collection will do a cleanup and makes all unused memory available.

Question is when does mono run a garbage collection on a script? Since that uses alot of resources that will happen very rare. By my observations that happens when the script occupies over 64k. For small scripts it may happens after quite a while or maybe never as long as 64k is not exceeded.

I'd expect that a reset cleans up everything though. If that is not the case - well - it's SL

In my case, script reset did not apply because I was making changes / recompiling.