Memory Usage - from the Wiki

[Wandering Soulstar]

While having my morning coffee I was browsing around the Wiki, as one does, and came across THIS PAGE from @Omei Qunhua  that I had not seen before. The really interesting section for me came at the bottom:

Quote

Auto-casting of integers to floats (Mono)

  llSetTimerEvent(0)  is 3 bytes shorter than llSetTimerEvent(0.0)
  llSetText(message, <1, 1, 1>, 1) is 12 bytes shorter than llSetText(message, <1.0, 1.0, 1.0>, 1.0)

Adding single items to a list (Mono) For ByteCode space-saving, don't form the new item into a list itself before adding.

example:

  list MyList;
  MyList += "a";   is  10 bytes shorter than     MyList += ["a"];
  MyList += 1;     is  15 bytes shorter than     MyList += [1];
  15 byte savings also apply when adding floats, vectors and rotations.

Counter intuitive, but good to know and something to take into account I would think. Also was intrigued by the last statement:

Quote

I've just developed a means of storing an avatar key losslessly in a quarternion, with help from work by Strife and Pedro. So that gives the chance to hold keys accurately in a list at just 28 bytes per key. Watch this space!

Since the wiki page has not been updated since May of 2014 .. would be very interested in seeing what came of this ... Omei, @Strife Onizuka, Pedro  .... are you there?

Edited March 22, 2019 by Wandering Soulstar
Added link

[steph Arnott]

Using integers as float saves nothing because when the script is run they are converted to floats which can cause issues.

I certainly would not trust compressing a key value.

Edited March 22, 2019 by steph Arnott

[Wandering Soulstar]

26 minutes ago, steph Arnott said:

Using integers as float saves nothing because when the script is run they are converted to floats which can cause issues. 

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:

Quote

If a function requires a float as a parameter, and the number is an integer (e.g. 5), you can add the .0 to clearly indicate it's a float, but omitting the .0 is equally valid and actually saves bytecode space in the compiled code.

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.

[steph Arnott]

1 minute ago, 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. Also integers are not converted to floats when compiled, they are converted every time the script  uses the value. What is happening is a very primative compression which has to be uncompressed to conform to the functions reqiured value type.

[Wandering Soulstar]

<sigh>

[Love Zhaoying]

The implication is, the parameters are pushed on the call stack (if indeed Mono uses a call stack) as integers, and the called function determines their type. Or, they are converted to floats before being pushed on the stack, but the fact they are integers prior to that saves memory. Either way, sounds legit.

[Qie Niangao]

Yeah, let's talk about the key thing instead.

When I was first starting out, I assumed LSL stored its (32 4-bit hex character) UUIDs in a tight 128-bit, 16-byte format. I was shocked to learn that it instead uses the fully expanded human-readable format, hyphens and all, and then bloats this further with storage code depending on how the key is used (e.g., in a list, in a global variable, in a local literal, etc). So there's definitely an opportunity to pack UUIDs tighter if there's enough of them to offset the space and time cost of compression/decompression.

And there's a wiki page dealing specifically with compression of keys. I'm not sure storing a key as a quaternion actually wins, compared to all these options, because quaternions aren't always stored all that efficiently either.

Incidentally, here's another wiki page about LSL memory use, from more contributors. It notes:

Quote

As the LSL compiler is not a simple program, the data below may not be 100% accurate, in fact, much of it is wrong and could use corrections.

which is a very good observation. The Discussion behind the page is also worth a glance, and its History -- if nothing else, to get a healthy skepticism that anybody really knows WTF they're talking about when discussing LSL memory usage.

Edited March 22, 2019 by Qie Niangao

[steph Arnott]

12 minutes ago, Qie Niangao said:

Yeah, let's talk about the key thing instead.

Well keys are not all equal status. Paste the key into this and it will throw an unsupported error.

llRegionSayTo(agent,0,"secondlife:///app/group/" + (string) groupKey + "/about");

 

[Love Zhaoying]

31 minutes ago, Qie Niangao said:

Incidentally, here's another wiki page about LSL memory use, from more contributors. It notes:

Quote

 As the LSL compiler is not a simple program, the data below may not be 100% accurate, in fact, much of it is wrong and could use corrections.

 which is a very good observation.

Thanks for this.

[Love Zhaoying]

33 minutes ago, steph Arnott said:

Well keys are not all equal status. Paste the key into this and it will throw an unsupported error.

llRegionSayTo(agent,0,"secondlife:///app/group/" + (string) groupKey + "/about");

 

At compile-time or runtime?

[steph Arnott]

Just now, Love Zhaoying said:

At compile-time or runtime?

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.

[Fenix Eldritch]

1 hour 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.

Please post the full example script where you get this to happen. I've tried to replicate what you claim, but each attempt successfully prints out the group link in chat. I'm not seeing a runtime error. Even supplying a bogus uuid (as a key or string) still does not produce a runtime error for me.

default
{
    state_entry()
    {
        list info = llGetObjectDetails(llGetKey(), [OBJECT_GROUP]); 
        llOwnerSay(llList2String(info,0));
        //I used Bay City Alliance group, uuid was "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e"
        
    }
    
    touch_start(integer total_number)
    {
        key agent           = llGetOwner();
        key groupKey        = "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e";
        string groupString  = "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e";
        
        llRegionSayTo(agent,0,"1. secondlife:///app/group/" + (string) groupKey + "/about");    //control
        llRegionSayTo(agent,0,"2. secondlife:///app/group/" + groupString + "/about");          //using string variable
        llRegionSayTo(agent,0,"3. secondlife:///app/group/" + "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e" + "/about");   //flat text 1
        llRegionSayTo(agent,0,"4. secondlife:///app/group/ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e/about");             //flat text 2
    }
}

 

[steph Arnott]

5 hours ago, Fenix Eldritch said:

Please post the full example script where you get this to happen. I've tried to replicate what you claim, but each attempt successfully prints out the group link in chat. I'm not seeing a runtime error. Even supplying a bogus uuid (as a key or string) still does not produce a runtime error for me.

The ouput format in the chat field is wrong, it should state the group name not a string.

secondlife:///app/group/secondlife:///app/group/b91a5bf4-d0f9-f2bb-1cfd-8a0e3ffa0d34/about/about
[11:49] Second Life: The SLurl you clicked on is not supported.

{
			list temp = llGetObjectDetails(llGetKey(), [OBJECT_GROUP]);
			key groupKey = llList2Key(temp, 0);
			//llRegionSayTo(agent,0,"secondlife:///app/group/" + (string) groupKey + "/about");

			llRegionSayTo(agent,0,"3. secondlife:///app/group/" + "secondlife:///app/group/b91a5bf4-d0f9-f2bb-1cfd-8a0e3ffa0d34/about" + "/about");
			llListenRemove(menu_chan_handle);
			llSetTimerEvent(0.0);
		}

Change it back to getting the objects group and it outputs correctly.

Edited March 22, 2019 by steph Arnott

[Fenix Eldritch]

Ok, what we have here is a miscommunication. I thought you were saying runtime error that resulted in a crash. That's on me for misreading it. What you appear to be talking about is the situation when the viewer's URI namespace is malformed. You're getting that "SLurl you click on is not supported" message not because you typed in a key as a string, but because you botched the formation of the SLurl in the first place.

19 minutes ago, steph Arnott said:

secondlife:///app/group/secondlife:///app/group/b91a5bf4-d0f9-f2bb-1cfd-8a0e3ffa0d34/about/about

The above attempt is always going to fail because you've got the format wrong. You're including some duplicate parts of the viewer URI namespace.

Try this and it works fine:

llRegionSayTo(agent,0,"3. secondlife:///app/group/" + "b91a5bf4-d0f9-f2bb-1cfd-8a0e3ffa0d34" + "/about");

It's the same UUID from your example, but without the extra "secondlife:///app/group/" and extra "/about" . That correctly resolves to the group "timelady of gallifrey" without issues. So the problem you saw was not caused by inputting the key as a string.

[steph Arnott]

1 minute ago, Fenix Eldritch said:

 

That can not be botched because i used the 'copy url' button and a manual copy. I had already tried the second way. It outputs the same. I did this the other day also because i could not remember why i used the code i did and was obviouse as to why as soon as i ran the code.

[Fenix Eldritch]

It is definitely botched. Look at this line again from your previous post:

36 minutes ago, steph Arnott said:

llRegionSayTo(agent,0,"3. secondlife:///app/group/" + "secondlife:///app/group/b91a5bf4-d0f9-f2bb-1cfd-8a0e3ffa0d34/about" + "/about");

See how you have "secondlife:///app/group/" twice? That's going to get jammed together into one big string which results in an incorrectly formed SLurl. Same with the "/about". You have it listed twice on the same line.

It's like if I tried to type in a web page url of "http://http://secondlife.com.com"

[steph Arnott]

5 minutes ago, Fenix Eldritch said:

It is definitely botched. Look at this line again from your previous post:

See how you have "secondlife:///app/group/" twice? That's going to get jammed together into one big string which results in an incorrectly formed SLurl. Same with the "/about". You have it listed twice on the same line.

It's like if I tried to type in a web page url of "http://http://secondlife.com.com"

I copied that off my external editor file after adding your part, the inworld is correct.  I just checked. I thought i had rectified the double entry before pasting  a few mins ago. Even if i put the string as a global variable it still throws up the error.

[Fenix Eldritch]

Uh uh. Look, the examples above have clearly established that if you post the group key as a string, the viewer has no problem resolving it into a functioning SLurl - providing there isn't some user error like in your previous example. I posted clear examples of it that anyone can replicate using the Bay City Alliance group, or even your own group. It does work.

So if you still insist that supplying a valid group key in the form of a string into a valid SLurl somehow produces an error, then you must give us a working code example. Not an anecdote, but an actual working example that consistently fails in the way you claim. Please provide a complete code example so that no misunderstanding can occur.

[steph Arnott]

1 minute ago, Fenix Eldritch said:

Uh uh. Look, the examples above have clearly established that if you post the group key as a string, the viewer has no problem resolving it into a functioning SLurl - providing there isn't some user error like in your previous example. I posted clear examples of it that anyone can replicate using the Bay City Alliance group, or even your own group. It does work.

So if you still insist that supplying a valid group key in the form of a string into a valid SLurl somehow produces an error, then you must give us a working code example. Not an anecdote, but an actual working example that consistently fails in the way you claim. Please provide a complete code example so that no misunderstanding can occur.

The error i posted was a typo taken from my external editor when i added yours. The inworld object is correctly formatted and was created last week. People do make errors when rushing you know. Still does not change the fact that the correct version throws an error. Also i just tryed six group keys, two work, four do not.

[Fenix Eldritch]

7 minutes ago, steph Arnott said:

People do make errors when rushing you know. Still does not change the fact that the correct version throws an error. Also i just tryed six group keys, two work, four do not. 

Which is precisely why I want to see the actual code in question. I want to understand what's happening that could possibly be responsible for the results you're seeing. It might be a another innocent user error. It might be some previously unknown flaw in LSL (though I honestly am less inclined to think so).

But the only way we can get a better understanding of whatever issue is going on is to all be on the same page. I mean no disrespect, but I simply can't take your word for it - not when I've seen and tested other examples that seem to contradict what you're saying. So again, please show us the code that is producing your error. I want to learn.

[steph Arnott]

1 minute ago, Fenix Eldritch said:

Which is precisely why I want to see the actual code in question. I want to understand what's happening that could possibly be responsible for the results you're seeing. It might be a another innocent user error. It might be some previously unknown flaw in LSL (though I honestly am less inclined to think so).

But the only way we can get a better understanding of whatever issue is going on is to all be on the same page. I mean no disrespect, but I simply can't take your word for it - not when I've seen and tested other examples that seem to contradict what you're saying. So again, please show us the code that is producing your error. I want to learn.

I passed it to another script writter who wrote their own from scratch and they have the same issue. It works on some and does not on others. Any how i will use the capture method i have done for years because there have been no issues in regards to group keys with that method.

[Fenix Eldritch]

Anecdotes and proof surrogates are not evidence. Why are you evading this? And if your capture method has had no issues, why are you getting inconsistent failures then? Doesn't that contradict what you just said minutes earlier?

[steph Arnott]

10 minutes ago, Fenix Eldritch said:

Anecdotes and proof surrogates are not evidence. Why are you evading this? And if your capture method has had no issues, why are you getting inconsistent failures then? Doesn't that contradict what you just said minutes earlier?

I already have the answer as to why. LL updated the version at some point and many older keys are not compatible with current urls as a string.

Edited March 22, 2019 by steph Arnott

[Fenix Eldritch]

And why did it take you this long to reveal that little nugget? Seems like that would have been pretty pertinent to know from the start of this conversation.

Please cite your source on that information. For LL to implement such a change that would break compatibility (which is something they normally try to minimize), I would expect to see some kind of announcement or at least comment about it.

And if that truly was the case, why didn't you provide us with a known old-style key that should by your own logic produce the error every time?

Edited March 22, 2019 by Fenix Eldritch

[steph Arnott]

1 minute ago, Fenix Eldritch said:

And why did it take you this long to reveal that little nugget? Seems like that would have been pretty pertinent to know from the start of this conversation.

Please cite your source on that information. For LL to implement such a change that would break compatibility (which is something they normally try to minimize), I would expect to see some kind of announcement or at least comment about it.

Because i asked a person whos career is a code writer to pop in to SL. Which they did as a favour.