Performance advice

[JustinMichael Torok]

Hello,

I'm working on making some of my scripts as fast/small as possible. I'm not interested in readability or form, just function and speed.

I have a few questions that I couldn't seem to find answers to by searching around here or on Google.

1. If I have a Menu System, say
   llDialog(llDetectedKey(0),"Menu\nSelect an option",["1","2","3","4","5","6","7","8","9","10","11"],1000);
    and I had to call that menu 2+ times in the script, would it be better to use a list variable for the buttons? Or to copy/paste the menu as it looks above?
2. If I have multiple "If" statements, as in
   if (a == b) llSay(0, "text");
   if (b == c) llSay(0, "other text");
   if (c == d) llSay(0, "last text");
    and only one of the possible if statements would be triggered, would it be better to do it as it looks in my example or should I use "else if" for the last 2 if statements?
3. I've seen people write their if statements like
   if ((a == b))
    instead of
   if (a == b)
    Is there an advantage to using "(())" instead of "()"?
4. I've also seen people write their floats like
   (float)1.5
    instead of just typing "1.5". Is there an advantage to adding the "(float)" typecast before the float?
5. Does the length of a timer affect the script's performance?
6. Does a phantom physical object have any performance gain over a regular physical object?
7. Is it better to compile smaller scripts as Mono and use
   llSetMemoryLimit(llGetUsedMemory()+0x1000);
   or compile them as LSL?

Any useful tricks you guys know that could help me out? Any tips are very much appreciated. =)

[Rolig Loon]

You might take a look at some of the collected wisdom on LSL script performance and efficiency in the wiki at

https://wiki.secondlife.com/wiki/LSL_Script_Efficiency

and

https://wiki.secondlife.com/wiki/LSL_Script_Memory

Some of your questions are addressed there.  You'll hear debate about most of the others in threads here in the LSL forum.  You may want to spend some time with the forum's admittedly frustrating search function.

A few specific comments:

1.  In general, it only makes sense to create a global list if you are going to need to call it from more than a couple of places in the script.  In your specific example, I would usually create a menu list as a local variable.  Circumstances make a difference, though.  If I am writing a script for a client and want to make it easy for him to update a variable, for example, I will make it global so that it sits in an easily accessible spot at the top of the script.  Convenience trumps performance in that case.

2. Go with "else if" and always filter the most restrictive case first.  If (a == b) is the least likely case and it's TRUE, then you won't need to go to all the trouble of asking about (b==c) and (c==d), which will often take longer to test.

3.  Adding parentheses never hurts, and they reduce ambiguity and often increase readability.

4. As far as I know, adding (float) won't affect performance.  It's unnecessary, but it can be helpful as a reminder when you come back to the script two years later (or someone else does).  For some reason, I see that done more often in particle script than anywhere else, perhaps because they are so often modified by amateur scripters.

5.  Yes, but don't get paranoid about it.  Avoid fast timers when you can, mostly because they add load on the sim's servers and increase competition for script time.  If you can't, as in most AOs, don't worry about it.

6. The physics engine doesn't have to go through all the collision calculations for a phantom object that it needs to do for a non-phantom object.  That's not a matter of script efficiency as much as a matter of building strategy, but it can dictate what options you have for moving objects and detecting interactions with agents and other objects.

7.  See the link posted above for scrfipt memory.

In general, although it makes sense to avoid unnecessarily inefficient coding, other considerations like readability are more important, IMO.

[JustinMichael Torok]

Thanks for the links and information. =)

I know what you mean about readability. The script I'm working on, however, just needs to be as fast as possible. It won't ever be seen by anyone other than myself, and I can read ambiguous code just as easily as well formatted code, so that's not an issue in this case. =)

Thanks again. =D

[LepreKhaun]

    1. What you have to realize here is that LSL has two kinds of variables (lists or otherwise)- named and literal. A named variable takes the form of

list myList;myList = ["1","2","3","4","5","6","7","8","9","10","11"]; 

This takes two distinctive parts- the declaration of the named variable in the first line and the assignment of that variable in the second (These can and often are combined into one statement.). The main point in seperating the two parts is that the second line assigns a literal (actually written out in the code) value to a named variable (which is a pointer to the value of that variable). When your code is compiled, having values written out in your code results in literal values held within your code body, resulting in increased script memory. Usage of a named variable in two or more places may result in a smaller size of your script memory but at the time-cost of having the VM reference the name to obtain the value. However, this is done so quickly that I seriously doubt one would ever notice any "lag" and the memory benefit will almost always win. Use the "Rule of 3" for this, if it appears 3 or more times within a script, a named variable is called for. And that goes double if the value is being obtained from an invariant function call (such as llGetOwner()).

    2. Makes a difference in time performance, use else if to chain conditional test(s) unless you require something further down the chain to happen (rarely, if at all within LSL).
    3. No difference. But note that (b == a) may sometimes be preferable to (a == b), just to catch the cases of when b is a constant but only to catch the (a = b) newbie error.
    4. Any type casting, whether needed or not, will "slow" performance (LSL doesn't optimize away unneeded instances AFAIK), However, I doubt you'd ever notice the difference, I can't with 10,000 repetitions.
    5. Unsure what you mean by "length of a timer".The timer is a event handler and will be triggered no more often than llSetTimer(1.0); has set the timer to fire (once every one second in this case). No events ever interrupt another; once an event has been triggered, the code within its event handler must finish executing completely before any further events (which a queued) can next be triggered. Performance may be hampered in any event handler that fails to execute and exit in a timely manner. Other events may be triggered while the timer is counting down in the meantime.
   6. Phantom objects have no positive impact on physics computation.

    7. Do not use llSetMemoryLimit(llGetUsedMemory()+0x1000);. You are essentially asking for 4K more than the "high tide" level at that point of your script. The script might well require more than that later. Either way, it will not make your script any more efficient timewise.

[Qie Niangao]

---

LepreKhaun wrote:

[...]

    5. Unsure what you mean by "length of a timer".The timer is a event handler and will be triggered no more often than llSetTimer(1.0); has set the timer to fire (once every one second in this case). No events ever interrupt another; once an event has been triggered, the code within its event handler must finish executing

completely

before any further events (which a queued) can next be triggered. Performance may be hampered in any event handler that fails to execute and exit in a timely manner. Other events may be triggered while the timer is counting down in the meantime.

   6. Phantom objects have no positive impact on physics computation.

    7. Do not use 

llSetMemoryLimit(llGetUsedMemory()+0x1000);. 

You are essentially asking for 4K more than the "high tide" level at that point of your script. The script might well require more than that later. Either way, it will not make your script any more efficient timewise.

---

I suppose we can't be sure, but I'll bet that "length of a timer" refers to the interval of the timer -- the "wavelength" side of its "frequency", so to speak. If so, then yeah: a short timer in one script can hurt performance of all other scripts in the sim. That's because the short timer script is trying to run so often. Note that even if it doesn't do much when the timer expires, it costs processor time every time a script event fires and it has to run at all.

Phantom objects are lighter on the physics engine than are non-phantom ones because, being phantom, they (generally) cannot cause collision-driven calculations. An exception would be objects set llVolumeDetect() which cause all the same collision events for scripts but are otherwise handled as if phantom; I'd guess that those cause about the same physics load as non-phantom objects (although they won't trigger chains of collisions).

Finally, it may be beating a dead horse, but llSetMemoryLimit() not only doesn't improve a script's time efficiency, it also doesn't affect its actual memory use, except in the case where it causes the script to crash for lack of memory it needs. Otherwise, it only affects the amount of memory the script reports that it's using. (Well, that, and it adds a small amount of memory itself as a function call in the script.) So unless somebody is threatening to penalize your script for how much memory it appears to use, llSetMemoryLimit() confers no benefit whatsoever.

[JustinMichael Torok]

Awesome advice, thank you!

I've had some customers in the past tell me that the owner of the sim/land they're renting has contacted them about the performance of my script. Generally this only occurs when the customer makes a dozen or more copies of the item. I'm trying to do my best to reduce the script's performance cost as much as possible so my customers can make many copies of the item on their land. =)