LSL Hacks

Template:Needs Translation/LSL/de Template:Needs Translation/LSL/es Template:Needs Translation/LSL/el Template:Needs Translation/LSL/fr Template:Needs Translation/LSL/he Template:Needs Translation/LSL/it Template:Needs Translation/LSL/ja Template:Needs Translation/LSL/ko Template:Needs Translation/LSL/nl Template:Needs Translation/LSL/hu Template:Needs Translation/LSL/no Template:Needs Translation/LSL/da Template:Needs Translation/LSL/sv Template:Needs Translation/LSL/tr Template:Needs Translation/LSL/pl Template:Needs Translation/LSL/pt Template:Needs Translation/LSL/ru Template:Needs Translation/LSL/th Template:Needs Translation/LSL/uk Template:Needs Translation/LSL/zh-Hans Template:Needs Translation/LSL/zh-Hant

/LSL

Hacks

A page dedicated LSL Hacks, those things that make your code so much better but at the same time so much worse.

llMessageLinked key parameter as string

VM: LSO

Discover: Unknown

Instead of passing a valid key as the forth parameter of the llMessageLinked function, a string value can be used. When the link_message event is triggered, the key can be typecast to a string (implicitly or explicitly) without any value degradation.

<lsl>llMessageLinked(LINK_THIS, 10, "Hello", "World!")</lsl>

Pros

• Allows for a second string to be sent to the receiving scripts
• Faster then splitting a single string into two.

Cons

• May no longer be a valid key value.

llGetListLength(myList) and (myList != [])

VM: LSO

Discover: Strife Onizuka

• Instead of using llGetListLength(myList) you can use (myList != []).
• Instead of using -llGetListLength(myList) you can use ([] != myList).

Pros

• Faster
• Uses less bytecode

Cons

• Less readable
• Will likely be removed in LSL3^[1]
• Mono's llGetListLength function has been optimized and is about 100% faster than list!=[];

++c and c++

VM: LSO

Discover: Not Applicable

In LSO LSL (as opposed to Mono LSL) ++c is faster than c++ because of how the bytecode is generated^[2]. There are very few applications where ++c can't be used instead.

Pros

• Faster code.
• Saves 6 bytes and 2 instructions.

Cons

• None

(c = -~c) same as ++c

VM: LSO

Discover: Strife Onizuka

For the same instruction cost of (++c), (c = -~c) can be substituted giving a 4 byte saves.

Pros

• Saves 4 bytes of bytecode.

Cons

• Will fail on hardware that doesn't support two's compliment (unlikely LL will ever use such a platform).
• Harder to understand.

Testing key validity

VM: LSO & Mono

Discover: Strife Onizuka

By passing the key value to a conditional, if it is valid and not a NULL_KEY then it will execute the true branch.

<lsl>integer isKey(key in) {

   if(in) return 2;
   return (in == NULL_KEY);

}</lsl>

Pros

• Fast
• Easy
• Painless

Cons

• Can give false positives if the variable type is not a key
• can only be tested by itself

if(~c) and if(c != -1)

VM: LSO

Discover: Unknown

Instead of using if(c != -1) you can use if(~c). This applies to all conditionals.

Pros

• Faster (60%)
• Uses less bytecode (6 bytes, 1 instruction)

Cons

• Harder to understand
• Only for Integers

myList = (myList = []) + and myStr = (myStr = "") + Hack

VM: LSO

Discover: Strife Onizuka

This hack works equally well for both strings and lists.

Instead of using myList = myList + addition you can use myList = (myList = []) + myList + addition which will in certain situations reduce memory fragmentation. Memory fragmentation can result in what appears to be a memory leak. This works because LSL execution is Right-To-Left, it frees the value stored at the variable's memory location after copying it to the stack but before storing the return back to the location; the result can be better memory compacting.

Pros

• Possibility of reduced memory fragmentation

Cons

• More costly in bytecode and slower
• Doesn't work in LSLEditor (LSLEditor uses Left-To-Right order of execution).
• No real benefit when used in Mono
• Possibility of slightly increasing memory fragmentation

Notes

• Be sure to test it both ways around before using this.
• This can also be used with any function.
  • llDeleteSubList((myList = []) + myList, x, y)

32bit hexadecimal notation instead of negative integer notation for constants (ex: 0xFFFFFFFF instead of -1)

VM: LSO (MONO unknown)

Discover: Void Singer

instead of using negative integer constants in code (does not apply to global declarations) use the 32bit hexadecimal notation. Works because the compiler does not optimize out the negation sign for integer literals (LSO confirmed, MONO unknown, but not harmful)

Pros

• Faster (one less operation)
• Less Byte Code (2 bytes saved on the operation)

Cons

• Harder to read

VM Detection

VM: Both

Discoverer: Void Singer

<lsl>(llToLower( "Ü" ) == "Ü"); //-- yields TRUE for LSO, and FALSE for MONO. (llToLower( "Ü" ) != "Ü"); //-- yields TRUE for MONO, and FALSE for LSO.</lsl>

• No Pros or Cons

VM Detection

VM: Both

Discoverer: Strife Onizuka

<lsl>(llGetListEntryType( (list)((key)"") ) & 1); //-- yields TRUE for LSO, and FALSE for MONO. (llGetListEntryType( (list)((key)"") ) >> 2); //-- yields TRUE for MONO, and FALSE for LSO.</lsl>

• No Pros or Cons

(c & 0x80000000) instead of (c < 0)

VM: LSO

Discover: Unknown

Instead of checking if an integer is less than 0 using the comparison operator, the bitwise AND operator can be used to check for the sign-bit. If the sign bit (0x80000000) is true, then the number is negative, and thus less than 0.

Pros

• Saves one byte

Cons

• Harder to understand
• Only for Integers

(c & power_of_two_minus_one) instead of (c % power_of_two)

VM: LSO

Discover: Unknown

Instead of using the modulus operator with a power of two (such as 2^2 or 4), the bitwise AND operator can be used with the value of the power of two minus one (such as 3 instead of 4).

<lsl>if(var & 3);</lsl> will work the same as <lsl>if(var % 4);</lsl>

Pros

• Saves one byte
• 500% faster in Mono.
• A few percent faster in LSL.

Cons

• Harder to understand

Multiplying by reciprocal instead of dividing

VM: Both

Discover: Unknown

Implementations of division as a whole are more complex than implementations of multiplication. This includes the algorithmic implementation on a hardware level. Because of this, multiplication is faster than division. Many compilers will automatically 'optimize' these sort of tiny things, but LSL doesn't seem to...

For example, x/2.0 will have the same output as x*0.5, but will run faster.

Pros

• A few percent faster in LSL with floats; about 10 to 15% faster in LSL with integers.
• About 600% faster in Mono with floats; about 1000% faster in Mono with integers.

Cons

• May be less intuitive depending on implementation.
• In the scheme of things, the time difference is tiny. Still interesting regardless!

Footnotes

1. ^ Plans for LSL3 are still being worked out, nothing has been finalized, no release date has been set, LSL3 may in-fact never happen.
2. ^ The LSO LSL compiler does not produce optimized code.