llMessageLinked - Key Memory

Some of my scripts use quite a few llMessageLinked functions. If I'm not passing any keys along, does it matter what I use in the key parameter as far as script memory is concern?

Examples:

1. llMessageLinked( LINK_ALL_OTHERS, 1, "ON(P)", llGetKey() );
2. llMessageLinked( LINK_ALL_OTHERS, 1, "ON(P)", "" );

I saw a wiki or something a whiles back that someone put together on how much (approx.) script memory each function took up. Does anyone have a link to that page?

Thanx

Unless the receiver of the message cares about the key, I'd leave it out. Not sure you save memory by doing this but you save time - if you include the key, the sim has to make a copy of it and pass that along to the destination.

If the key is irellevant to your needs an empty string uses less memory than a NULL_KEY and requires less processing.

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

It's a case of "" vs. "00000000-0000-0000-0000-000000000000". No contest.

I think keys are passed around as strings so it's not a whole bunch of 0's vs a real key, it's "" vs a real key.

edit: er.. right. I think that's what you were saying, too. If you don't need the key value, use "", not NULL_KEY.

edit: related: http://jira.secondlife.com/browse/VWR-7362

I had done a copy/paste on a multitude of llMessageLinked functions with llGetKey in it going back only to mod the string being passed but had left the llGetKey in each one.

I just took that script and did a llGetFreeMemory on it with llGetKey (4163 and then without llGetKey (43174). A savings of 2.5K on this particular script. Doesn't seem like a whole lot. I guess it makes a difference in overall sim mem allocation?

Thanx for your responses!

Storing the vaue of NULL_KEY once in a script isn't going to make that much of a difference compared to using an empty string. But LSL parameters are passed by value - i.e. a null key is created in full and added to the stack every time it's used as a function parameter, and the null key is transmitted in full when it's used in something like a link message - all things that add to memory usage, processor time and thus server load.

I'd argue that in a 16K LSO environment 2.5K is huge, and that it's still pretty significant in a 64K mono environment. In the case of the example you quote, I'd guess that the unnecessary call to llGetKey () is the major problem, in terms of script memory, stack usage and processing time.

Are you saying that passing "" will get translated into a full NULL_KEY value?

If so, I don't think that's the way it works - I think it's just a string. Guess somebody could try passing an invalid key ("meade was here" or whatever) in that argument and see how it turns up on the other end.

If this script ran fine as an LSO with 16kb and I convert it to mono taking up about 21k it seems I'm losing out on the diff of 5K right there. Maybe I should leave it LSO (without the llGetKey of course)?

The code we talk about is compiled into a VM code.
Is there anybody who knows for certain, that
will not compile into the same VM code?
It could very well be the case

If the script is in an attachment or an object that's rezzed regularly I'd definitely recommend compiling as LSO so as to avoid the mono lag spike when rezzing or moving to a new sim. If speed of execution is an issue than I'd recommend mono.

And if it's in something that's permanently rezzed... Well I guess I'd wait and see (a) which does better when the script performance monitoring tools become available in advance of script limits coming into effect (or, if you know an amenable sim owner, you might ask them to tell you how they compare using the Top Scripts tool), and (b) what the more technically adept contributors to this forum have to say about it.

It's in an object that stays permanently rezzed. I get the same script time no matter which way it's compiled. My concern is the upcoming limits as you mentioned. I've been going back over all my scripting trying to make things as efficient as possible. And I am catching some early blunders... lol

I wouldn't worry too much about the script limits yet. Better to look at your code for extra stuff you're doing that you don't need to be doing. In this particular case, if the receiving script does not need a key value, pass "" for the key.

No, I think we're both saying the same thing. "" remains "", but NULL_KEY becomes "000... etc.".

There is the exception mentioned in the discussion of the EMPTY_KEY JIRA you referred to, where one of the Lindens says that in llListen an empty string is expanded to a full NULL_KEY, but it's not clear whether they mean this happens at run time or on compilation.

I can say with certainty that "" is more efficient than NULL_KEY, and in a link message will save you some space if you aren't using the key (although you CAN use the key field to hold other text values besides keys)

if you evaluate a key "" will be interpreted as NULL_KEY for purposes which require a key, but it will NOT be converted to NULL_KEY

there may be an exception in listens/sensors (on the server side only, if so), but I don't believe that to be the case (pretty sure it tests key validity the same way as the scripting engine).

sending "" is smaller in your sending script AND your receiving script

Yes. Here is an easy demonstration.

default
{
    touch_start(integer total_number)
    {
        llMessageLinked(LINK_THIS, 1, "", NULL_KEY);
        llMessageLinked(LINK_THIS, 2, "", "");
    }

    link_message(integer sender, integer num, string str, key id)
    {
        integer isNull = (id == NULL_KEY);
        llOwnerSay("num " + (string)num +
                   " id <" + (string)id + "> isNull " + (string)isNull);
    }
}

[12:29] Object: num 1 id <00000000-0000-0000-0000-000000000000> isNull 1
[12:29] Object: num 2 id <> isNull 0

...and if you use this instead?

integer isNull = TRUE;
if (id)
isNull = FALSE;

edit: and integer isNull = (id) might work, too. Dunno.

Empty keys and NULL_KEY both evaluate to FALSE in if(), but an empty key is not equivalent to NULL_KEY. This is only so if they are type key. As strings NULL_KEY will evaluate to TRUE and "" will evaluate to FALSE.