Difference between revisions of "LSL Hacks"

From Second Life Wiki
Jump to navigation Jump to search
(New page: {{Multi-lang}} {{LSL Header}} {{RightToc}} A page dedicated LSL Hacks, those things that make your code so much better but at the same time so much worse. {{#if: {{#vardefine:p_myList_des...)
 
Line 10: Line 10:
}}
}}
== [[llGetListLength]]({{LSL Param|myList}}) and ({{LSL Param|myList}} != []) ==
== [[llGetListLength]]({{LSL Param|myList}}) and ({{LSL Param|myList}} != []) ==
'''Type''': LSO Optimization <!-- Discovered by Strife Onizuka -->
{| {{Prettytable}}
| '''Type''': LSO
| '''Discover''': Strife Onizuka
|}


*Instead of using <code>[[llGetListLength]]({{LSL Param|myList}})</code> you can use <code>({{LSL Param|myList}} != [])</code>.
*Instead of using <code>[[llGetListLength]]({{LSL Param|myList}})</code> you can use <code>({{LSL Param|myList}} != [])</code>.
Line 24: Line 27:


== ++c and c++ ==
== ++c and c++ ==
'''Type''': LSO Optimization <!-- Not attributable do to obvious nature -->
{| {{Prettytable}}
| '''Type''': LSO
| '''Discover''': Not Applicable
|}


In LSO LSL (as opposed to Mono LSL) ++{{LSL Param|c}} is faster then {{LSL Param|c}}++ because of how the bytecode is generated{{Footnote|The LSO LSL compiler does not produce optimized code.}}. There are very few applications where ++c can't be used instead.
In LSO LSL (as opposed to Mono LSL) ++{{LSL Param|c}} is faster then {{LSL Param|c}}++ because of how the bytecode is generated{{Footnote|The LSO LSL compiler does not produce optimized code.}}. There are very few applications where ++c can't be used instead.
Line 37: Line 43:


== ({{LSL Param|c}} = -~{{LSL Param|c}}) same as ++{{LSL Param|c}} ==
== ({{LSL Param|c}} = -~{{LSL Param|c}}) same as ++{{LSL Param|c}} ==
'''Type''': LSO Optimization <!-- Discovered by Strife Onizuka -->
{| {{Prettytable}}
| '''Type''': LSO
| '''Discover''': Strife Onizuka
|}


For the same instruction cost of <code>(++{{LSL Param|c}})</code>, <code>({{LSL Param|c}} = -~{{LSL Param|c}})</code> can be substituted giving a 4 byte saves.
For the same instruction cost of <code>(++{{LSL Param|c}})</code>, <code>({{LSL Param|c}} = -~{{LSL Param|c}})</code> can be substituted giving a 4 byte saves.
Line 49: Line 58:


== Testing [[key]] validity ==
== Testing [[key]] validity ==
'''Type''': LSO & Mono Optimization <!-- Discovered by Strife Onizuka -->
{| {{Prettytable}}
| '''Type''': 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.  
By passing the key value to a conditional, if it is valid and not a NULL_KEY then it will execute the true branch.  

Revision as of 09:20, 19 May 2008

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

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

Type: LSO Discover: Strife Onizuka

Pros

  • Faster
  • Uses less bytecode

Cons

  • Less readable
  • Will likely be removed in LSL3[1]

++c and c++

Type: LSO Discover: Not Applicable

In LSO LSL (as opposed to Mono LSL) ++c is faster then 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

Type: 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).
  • ?

Testing key validity

Type: 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

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.