Difference between revisions of "LSL Hacks"
Milo Madzuko (talk | contribs) |
Void Singer (talk | contribs) (another micro optimization the compiler misses) |
||
| Line 15: | Line 15: | ||
|} | |} | ||
Instead of passing a valid key as the forth parameter of the llMessageLinked function, an string value can be used. When the link_message event is triggered, the key can be typecast to a string ( | Instead of passing a valid key as the forth parameter of the llMessageLinked function, an 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> | <lsl>llMessageLinked(LINK_THIS, 10, "Hello", "World!")</lsl> | ||
| Line 134: | Line 134: | ||
* This can also be used with any function. | * This can also be used with any function. | ||
** <code>llDeleteSubList((myList = []) + myList, x, y)</code> | ** <code>llDeleteSubList((myList = []) + myList, x, y)</code> | ||
== 32bit hexadecimal notation instead of negative integer notation for constants (ex: 0xFFFFFFFF instead of -1) == | |||
{| {{Prettytable|style=margin:0;}} | |||
| '''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 | |||
= Footnotes = | = Footnotes = | ||
{{Footnotes}} | {{Footnotes}} | ||
Revision as of 12:50, 31 May 2010
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
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, an 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
++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
- None
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 = []) and (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