Script optimization

I seem to remember a thread where Strife Onizuka mentioned that it is more efficient to write the following code:

integer x = 0;

as

integer x;

My questions are:

Is it safe to assume that LSL will always assign 0 to an integer variable when it's declared?

On a similar note, is it safe to assume that LSL will always assign "" to a string variable when it is declared?

:0 i'd say 'generally' sure, except for keys - be sure to set those =NULL_KEY. i've gotten occassional garbage runs from my scripts on occassion if keys aren't set null up on top to begin with...

Integers are interesting, as they will default-value to 0 for mathematical operations, but they will NOT default to a value of "FALSE".

Example:

integer x;

default
{
     state_entry()
     {
          x += 2;

          if(x != 2) llSay(0, "failed");
          else llSay(0, "success");
     }
}

The above will say "success".

HOWEVER ...

integer x;

default
{
     state_entry()
     {
          if(x != FALSE) llSay(0, "failed");
          else llSay(0, "success");
     }
}

...will say "failed".

Keys, as well, as the above poster stated, should be set to NULL_KEY if you need to test against them before declaring them in code.

I'd call that a bug.. LSL doesn't have a boolean type so 0 and FALSE should be the exact same thing.

It is best to always be explicit and initialize all of your variables in any case. Even if the VM absolutely ENSURED everything gets initialized, it makes your code a lot more readable and maintainable (plus "portable" if it is even worth mentioning for LSL) to explicitly assign a value. So I'd advise you either do it right where you declare the variable or unconditionally in your default/state_entry.

That was my thought as well. It does correctly recognize (x == FALSE) for whatever that's worth. But it's good to know about not recognizing (x != FALSE) properly.

I've gotten in the habit of creating a load_defaults() subroutine at the top of my scripts. In it I set all of my global variables. Then in state_entry, I check to see if the notecard has been read yet, if it hasn't I load_defaults() first, then switch to another state to load the notecard. This way, if settings are missing in the notecard the defaults will already be there and your script will function properly. Also, it allows you to be more lenient in your notecard parsing code; if a setting is out of range or not there then you don't have to worry about it, just give the user a notice about the notecard error and let the defaults take over.

On a side note, if you script enough you'll start developing snippets of code that you can move from one script to the next. I've created a library of items I use regularly. One is a notecard configuration shell. I can start a script with that and then add in other snippets, customize and the script is done. Saves a lot of time.

It's never safe to assume anything related to compiler behavior.

Always assign defaults in my opinion. The "efficiency" in this case
is vastly outweighed by the inefficiency of code that may break at
any moment by a compiler implementation change.

Leaving anything in an undefined state is poor practice.

Have you ever read any optimised LSL?

Changing the value of a variable in the middle of a string operation involving it and subtracting one from an integer by using unary negation and a bitwise NOT probably aren't great practice either...

I find this hard to believe! FALSE is identical to zero.

I believe that key variables are initialized to (key)"", but I wouldn't rely on that in my code.

I see a lot of optimized code like this:

integer ix;
for (; ix < COUNT; ++ix) 

It's guaranteed to work by the language rules, but I just can't get my fingers to type it.

For globals that are card-configurable, it's important to re-initialize them explicitly, which I do in an init function called before the cards are read. I've seen plenty of code that makes the mistake of assigning these globals at declaration. This won't give the default behavior if you remove a line from the notecard. (Note that if you always reset the script whnn reading notecards, it's fine to initialize them at declaration.)

A very wise person once gave me these rules about optimization. In a 3-decade career as a software engineer in particularly difficult fields (embedded real-time control and communications), I've found it to be invaluable advice.

1) Optimize algorithms, not code
2) Learn to recognize the rare cases that are exceptions to rule 1.

In general, write your code for clarity, not speed. You won't regret it.

Bad practices all...

This ^^^ hehe

Sure, but unfortunately, sometimes in LSL it comes down to mylist = llListReplaceList(mylist=[], ... or stack/heap collision.

I respectfully disagree. You have to assume that the compiler implements the rules of the language. Otherwise, you can't write any code at all.

Unfortunately, LSL isn't formally defined. In particular, for function calls, we have to rely on behavior as a guide to intent since the functions calls are not sufficiently documented by LL. (The Wiki doesn't count: that's written by users, based on experimental results.)

However, I believe that the initialization behavior for integer and string variables is documented*by LL*, and if so, it is safe to rely on them. It's also safe to rely on this because it's behavior that's assumed by a huge number of existing scripts. If the compiler changed this behavior, you'd hear a hell-fire storm of criticism in response.

Whether it's *wise* to rely on them is another issue, as discussed in a number of cogent posts above.

lol!...perfectly expressed!

Note that this does not apply to Mono-compiled code. It's no longer necessary to use the following to append to a list, for example:

mylist = mylist + (mylist=[]) + newitem;

If that's the correct form, which I've forgotten, since I now use the much clearer form:

mylist += newitem;

We're agreeing then...

It IS safe to assume the compiler will initialize 'integer x;'.
It is NOT safe to assume what that value will be.

Whether or not you believe it - it's true. Tested, confirmed, etc.

Er.. I don't think that's what Lear was saying..

To me it seemed like Lear was quibbling over semantics over what "behavior" means...

In my opinion, purpose is the compiler performing its function and behavior the
way in which it executes the purpose. So initializing declared variables is the
compiler fulfilling its purpose. The specific choice as to the value used to initialize
a declared variable is behavior.

So...
It is safe to assume it will perform its purpose and unsafe to assume how it will
do so...

If it fails to perform its purpose, that's a bug in the compiler.
If it performs its purpose in a way that produces errors in your code, that's
a bug in your code.

We agree there.

Now on the other parts of the post, I don't think we agree. For instance I don't
agree that it's safe to rely on documented behavior. Being documented does
not make it immutable. I have seen plenty of instances of documented
behavior changing, often unpredictably and without documentation change.

But hey, generally I agree with Lear in this thread. I'm just more paranoid
than Lear

Well, it seems I'm out of date.

Back in 2006, SL came with a set of HTML files documenting LSL (poorly). IIRC, that documentation did state that integers were initialized to zero and strings to "". However, I can't find it.

The Wiki is silent on the issue.

So, at one time, the LSL compiler was required, according to official LL documentation, to initialize variables as mentioned above.

It's no longer required to. Frankly, it's no longer required to do *anything*, since there is no official documentation.

Therefore, don't write scripts. You can't count on the compiler to do anything.

I tried it; it prints "success", whether compiled by Mono or LSL. Cut/pasted it verbatim:

integer x;

default
{
     state_entry()
     {
          if(x != FALSE) llSay(0, "failed");
          else llSay(0, "success");
     }
}

Conditions:

Second Life 1.22.1 (103637) Nov 21 2008 14:59:21 (Second Life Release Candidate)
Release Notes

You are at 137643.7, 312488.9, 609.0 in Haguna dAlliez located at sim384.agni.lindenlab.com (64.154.221.70:13002)
Second Life Server 1.24.9.98659

LOL

If so, that's a bug.