Difference between revisions of "LSL Script Efficiency"
Gigs Taggart (talk | contribs) |
Gigs Taggart (talk | contribs) |
||
Line 34: | Line 34: | ||
* '''Never''' put a script in each prim (of a large linkset) that listens on channel 0 (or any other channel). This is probably the worst thing you can do for efficiency. Unfortunately it is all too common. | * '''Never''' put a script in each prim (of a large linkset) that listens on channel 0 (or any other channel). This is probably the worst thing you can do for efficiency. Unfortunately it is all too common. | ||
* Consider using [[XyzzyText]] instead of [[XyText]]. | * Consider using [[XyzzyText]] instead of [[XyText]]. | ||
The bottom line is, if you find yourself tempted to put a script in each prim, stop and think about how you could do it differently with less scripts. There is almost always an alternative. It is up to you to decide whether the alternative is a viable one for your application. | |||
</div></div> | </div></div> |
Revision as of 13:01, 22 July 2007
LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
What is Efficiency
Efficiency is how much resource a particular script uses to accomplish a goal. This often goes hand-in-hand with speed of execution, but not always.
Things to watch out for, in rough order of importance:
- Using a lot of scripts to accomplish something. See Efficient Design.
- llSleep - This function uses up 0.2 to 0.3 ms per frame while the script sleeps, timers are much better.
- Short frequency timers (<5 sec)
- Listen - especially to the 0 channel
- Changing textures often (Others have to download them)
- Inappropriate use of server/physical rotations instead of omega
- Event handlers which are not needed (touch, collision, ...)
- Large amount of email or IM
- Inefficient algorithms (like linear search)
- Busy (polling) loops
Efficient Design
Each idle script in an object adds 0.001 to 0.003 milliseconds per frame of script time usage. Less scripts is better.
- If you need to have a bunch of "buttons", don't put a script in each prim. Use llDetectedLinkNumber to detect which button was touched from your main script instead.
- If you need to change color, alpha, or texture of child prims, do not put a script in each prim. Instead use llSetLinkAlpha, llSetLinkColor, llSetLinkTexture, or llSetLinkPrimitiveParams.
- Never put a script in each prim (of a large linkset) that listens on channel 0 (or any other channel). This is probably the worst thing you can do for efficiency. Unfortunately it is all too common.
- Consider using XyzzyText instead of XyText.
The bottom line is, if you find yourself tempted to put a script in each prim, stop and think about how you could do it differently with less scripts. There is almost always an alternative. It is up to you to decide whether the alternative is a viable one for your application.
Micro-optimization
There are many ways to speed up scripts, such as using ++a instead of a++, however, most of those micro optimizations might not hold true in the future.
Rules for posting
1. Don't add theories.
2. Don't write "x is faster than y", write, "x takes X millis, y takes Y milis".
The following code will get the time for each function call in millis.
Please do not modify the script below, as any small change could change efficiency. Thanks to Xaviar Czervik for the original code, and Strife Onizuka for optimizing the code.
//IMPORTANT: Only perform tests in an empty region. // To reduce contamination and be sure to wearing no attachments. // Preferably do tests in a private sim with one on it. // Don't move while performing the test. // There is a margin of error so run the tests multiple times to determine it. integer time() { string stamp = llGetTimestamp(); return (integer) llGetSubString(stamp, 11, 12) * 3600000 + (integer) llGetSubString(stamp, 14, 15) * 60000 + llRound((float)llGetSubString(stamp, 17, -2) * 1000000.0)/1000; //llInsertString(llDeleteSubString(stamp, 19, 19) + "000000", 23, ".") } default { state_entry() { //test variables float counter; //framework variables float i = 0; float j = 0; float max = 10000; float start = time(); do { //test counter += 1; }while (++i < max); float delta = time(); do ; while (++j < max); float end = time();//remove the time required by the framework float t = ((delta - start) - (end - delta))/max; llOwnerSay("The function in the loop took a total of " + (string)t + " milliseconds."); } }
Efficiency
While the following data is correct, the function above was not used. A slightly less optimized version written by Xaviar Czervik was used. If someone could please repeat the tests with the function above.
In theory, ++a and a += 1 are equal in speed, however this is not true:
++a: 0.364700 millis a += 1: 0.346900 millis a++: 0.413700 millis
Testing the same function in for loops:
++a: 0.358370 millis a += 1: 0.351200 millis a++: 0.424600 millis
llOwnerSay v. llSay v. llShout v. llWhisper (Channel 0 where applies):
llOwnerSay(): 4.359000 millis llWhisper(): 5.201000 millis llSay(): 5.226000 millis llShout(): 14.877000 millis
Different Channels (llSay() Used for all):
-100000000: 1.226400 millis -100000: 1.254300 millis -100: 1.296100 millis -1: 1.292400 millis 0: 5.226000 millis 1: 1.242300 millis 100: 1.249100 millis 100000: 1.219700 millis 100000000: 1.228700 millis
Amount of text (llSay() and Channel 1 used for all):
1 Character: 1.242300 millis 10 Characters: 1.309700 millis 100 Characters: 1.965600 millis