Efficency(?) vs Readability

[Wandering Soulstar]

Good Morning All,

Have a question for all in general .. and hopefully will be an interesting discussion and stays on track 😉

What is your preference in the following option for readability compared to possible efficiency:

//readability

integer x;
integer len = llGetListLength(gSomeList);

for (x = 0; x < len; x++)
{
    //lines and lines of code
    integer worker;
    //do a bunch of stuff with worker
}

//efficiency

integer x;
integer len = llGetListLength(gSomeList);
integer worker;

for (x = 0; x < len; x++)
{
    //lines and lines of code
    //do a bunch of stuff with worker
}

My assumption in regards to the efficiency example is that it is somewhat faster to instantiate worker once, outside the loop, rather than be instantiating (and destroying) the variable n times inside the loop. That said ... if there is a lot of code from the start to where we first encounter worker we have lost in readability.

So .. is there a real gain in efficiency that we would notice? Would this on the macro scale, i.e. sim wide, make a difference if 'everybody' coded like this? Is it worth the loss of readability?

 

[Profaitchikenz Haiku]

Without knowing how the bytecode is optimised you can only guess, or test.

I agree with your assumption that the local-scope variable inside the loop might have an extra penalty, but the bytecode  compiler might create it only once when it sets up the loop, probably using stack space, and so there would only be one create and on destroy action, not x times.

Make a script that runs each version 1000 times, recording the start and end times of the test, and compare the elapsed time.

[Coffee Pancake]

Readability in LSL almost always comes at the cost of slower execution and greater memory use.

The servers aren't short of memory though and in the example case, the difference in execution will be negligible.

Generally, I tend to go for readability till my script threatens to spill over into more than one, then I will start optimizing for size and moving stuff inline.

[Mollymews]

for the CIL compiler it doesn't make any difference. Local variables are initialised by the compiler at the head of the function  (in the same way that Pascal does it) 

for both methods posted then the resulting CIL code looks like this:

.entrypoint
.maxstack 2
.locals init (
   int32  V_0,
   int32  V_1,
   int32  V_2,
   bool   V_3)

IL_0000: ... code starts here ...

the bool is added by the compiler, the bool value is used to determine when to break out of the loop

[Da5id Weatherwax]

Why can't you have both? If, in the name of efficiency, you must write less "readable" functional code, the humble comment can do wonders for readability. Using your "efficient example"

//efficiency + readability

integer x;
integer len = llGetListLength(gSomeList);
integer worker; //workspace for list iterator

for (x = 0; x < len; x++)
{
    //lines and lines of code
    // integer worker - global for efficiency.
    //do a bunch of stuff with worker
}

 

[Mollymews]

i just add to the conversation that the LSL Mono/CIL compiler doesn't always follow the CIL book. LL have a custom-made compiler. For example this code snippet is allowable on LSL compiler (which follows Standard C language conventions) and on LSL Mono compiler

default
{
    state_entry()
    {
        integer x = 1;
        if (x)
        {
           integer x = 2;
           llSay(0, (string)x);
        }
        llSay(0, (string)x);
    }
}

i think that when LL ported LSL to Mono/CIL then they had to follow the C conventions in building their CIL compiler so that LSL scripts could be compiled to Mono/CIL without breaking them, which would have happened to some scripts had they not. The standard Mono/CIL compiler would raise a compile time error on this code snippet