Keys require 48 bytes?!

I took two simple scripts to test the size of a key, the scripts were as follows:

integer i = 0;
default {
    state_entry() {
        llOwnerSay((string)llGetFreeMemory());
    }
}

Result: 16162

key k = NULL_KEY;
default {
    state_entry() {
        llOwnerSay((string)llGetFreeMemory());
    }
}

Result: 16118

This seems to suggest that the difference in size is 44 bytes. An integer is 4 bytes, meaning that a key is 48 bytes in size!

Seems to me that this is an absolutely ridiculous amount of overhead, considering a UUID is supposed to represent a 128-bit number (16-bytes).

Does anyone know why this is the case? I'm trying to make an efficient script since the functionality I need isn't easy to abstract out into several scripts with link-messages, but seriously, are they trying to make it difficult for us?

I can't even split it into 4 integers, as that takes up even MORE space with the overhead of lists =(

Close..

http://wiki.secondlife.com/wiki/LSL_Script_Memory

edit: er.. are you sure you've got the right results with the right scripts?

Those are the scripts that I used, only difference being that in one I declare an integer, in the other I declare a key. The reason being that there seems to be a cost associated with just declaring a variable. I get similar results by adding keys to a list, for example if I have a list with [NULL_KEY] then a list with [NULL_KEY, NULL_KEY] then I find a 48 byte difference again, which I found especially odd.

Keys are just strings, and your results match what's on that page.

NULL_KEY is equivalent to "00000000-0000-0000-0000-000000000000" (ie, it is a string literal, not a variable reference).
18 + 36 (1 per character) = 54.
54 (key declaration) - 10 (integer declaration) = 44.
16162 - 16118 = 44.

Oh.. Wait.. Free memory..

Sorry - I was, for no good reason, thinking it showed used memory and was wondering why the int was taking more. Never mind..

Then what I'd like to know is why are keys stored as strings when UUIDs are supposed to be the hexidecimal representation of a 128-bit number? It just seems unnecessarily costly with the only advantage being that they're much easier to cast to strings =S

Because LSL was written in a day, and never intended to be taken seriously.

depending on their backend setup...
maybe because it's easier to search a string than 4 conglomerated integers...

or maybe because it's easier to store a fixed length string than a series of integers...

or maybe it was just a fact of being built on a sytem already in place...

it could have even been to make it more human readable w/o having to convert them.

could be laziness and it was faster to reuse the string type than another for keys

interesting side note, keys take less space in lists than 4 integers (I'm guessing the overhead is because of items in a list being treated by default as strings, whith the added 5 byte overhead being flags to denote other types)

ref:

Hmm. I'm actually wondering why it isn't 72+ bytes. Doesn't SL use a 16-bit character encoding, making each character two bytes?

Anyway, you could always pack a key into fewer characters. You can get rid of the constant dashes '-' right off the bat, sneaking them down to 32 characters. Then you can encode them using more than just the characters 0-9, a-f. Using a Base64 type encoding, you could drop it down to like 21.333_ (call it 22 for simplicity) characters. And that's not a very tightly packed encoding, even. Then, if you really want to pack 'em in there, store all your keys in one big string, rather than a list. Heh.

EDIT: Oh. Downside being that such encoded keys won't prevent garbage collection, so don't use it to keep track of resources such as textures, notecards, sounds, etc. unless you are sure they are also in inventory somewhere.

SL uses UTF-8 I believe, which means that all (or most) ASCII characters still use only 1-byte per character.
Packing/unpacking to a different string format unfortunately will likely cost too much for me in terms of performance, while packing/unpacking to 4 integers would have been much easier. Oh well, looks like I'm just going to have to hope, or really limit my script.

It's a HUD engine btw that I'm working on for anyone interested, will use notecards to read in (on demand) the buttons to display on each menu screen and also to style the HUD itself. This is to replace a monstrous, rapidly developed HUD which has one-script per prim for 50-prims total! Eeep. I'm hoping to reduce it to 1 script + 5 helper scripts to do the llSetLinkPrimitiveParams() calls, this way I can put the helpers to sleep when idle.