Fixing slow scripts

Creating scripts
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: Fixing slow scripts

Post by Ilan Tochner »

Hi Kayaker,

There is something to what you're saying but if we continue counting the time spent in llSleep then the Top Scripts dialog may get filled with scripts that are not the worse offenders CPU-wise thus preventing people from learning what scripts they need to optimize or disable to reduce lag.
These users thanked the author Ilan Tochner for the post:
Alexina Proctor
User avatar
Marstol Nitely
Posts: 480
Joined: Mon Dec 24, 2012 1:42 am
Has thanked: 1019 times
Been thanked: 432 times

Re: Fixing slow scripts

Post by Marstol Nitely »

Help me out here please. I was originally reading Oren's blog post like Dot and paying more attention to the Statistics box. After reading Graham's post about particles I rechecked the chandelier (which is phantom) in Region Debug. When turned on it showed in top scripts at what appeared to be a much higher number above 1 ms. When off, if I waited a bit before checking again it didn't show at all. I think this is a great tool, but I need to understand it in order to explain the results to people buying scripted items.

What is a bad number for a script that shows below 1 ms in Statistics, but shows in Top Scripts at a higher number?
Do I leave items like the chandelier on the market with a disclaimer that using too many at one time might cause lag?
Since it doesn't seem to have any script cost unless turned on, should I just tell people to turn off the lights behind them if they use more than one?
Anything else I or my customers should know that I'm missing?
User avatar
Dot Matrix
Posts: 1625
Joined: Sun Jul 28, 2013 3:26 am
Has thanked: 1208 times
Been thanked: 2324 times

Re: Fixing slow scripts

Post by Dot Matrix »

Ilan wrote:In physical terms, consider a thrown ball without friction or other external forces acting on it. Once you know the vector you don't need to update the viewer again until the ball has another force acting on it.
May I give an example to understand more, please?

In the underwater area of Skysong (part of Intersections -- look for the red tent with the houseboat nearby) are groups of jellyfish which appear to drift slowly through the water. They are linked, phantom, and rotate on a circular path relative to the central base prim. Their fronds are flexi prims.

Would the defined rotation of the base prim be enough to give the vector, or would the extra vectors required to define the relative positions of the jellyfish cause the viewer hiccups? And are the flexi prims a nightmare in causing lag?
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: Fixing slow scripts

Post by Ilan Tochner »

Hi Marstol,

Statistics show the total time it took all the running scripts to run in the last frame that was sampled whereas Top Scripts displays the total time it took single scripts to ran over a 30 second period. If you disable a script it may therefore take it 30 seconds until it will no longer be within the time frame that Top Scripts displays.

The best way to test your script's effect would be to disable all other scripts in your world and have only a single instance of that script running. Statistics will then only display that script's runtime. The amount of time it takes will then give you an indication of how much load each script instance creates.

Keep in mind that the more often a script is called to change the world state the more server resources it will use. One way to potentially reduce a script's overhead is therefore to have it become active at a reduced frequency or have it have a mode where it doesn't actually change the world state (at all, or unless someone is close enough to it to see the effect the script creates). For example, have an option for the chandelier's candles to be static unless someone is within 5m of them and can therefore actually tell whether or not the candles are flickering. Make sure that the test you create won't be one that consumes a lot of CPU by itself (so don't constantly check if anyone is near, wait a few seconds between each check or, preferably, have this check be trigger based).
These users thanked the author Ilan Tochner for the post (total 3):
Marstol NitelySelby EvansAlexina Proctor
User avatar
Oren Hurvitz
Posts: 361
Joined: Sun Dec 23, 2012 8:42 am
Has thanked: 19 times
Been thanked: 499 times
Contact:

Re: Fixing slow scripts

Post by Oren Hurvitz »

I'm afraid I may have sounded more authoritative in the blog post than I actually am... Where I mentioned specific values, such as "a Script Time under 1 ms is good", that was based on my experience with worlds that have such performance. But I can't say with certainty where the dividing line is between acceptable and unacceptable performance.

The best indicator I have isn't even visible to users: Ilan and I have an admin panel that shows us statistics about every active world, including its CPU usage. That's the truest indicator of world performance, because it's a combination of EVERYTHING that's going on in the world: physics, scripts, avatars, etc. -- and it has a direct effect on how laggy the world feels. Because this information is so useful, we've decided that in the next release we're going to make this part of our admin panel visible to world owners. So when one of your worlds is active, you'll be able to see its true performance in real-time. If you see that your CPU usage is low then all the other statistics don't really matter. If it's high, then you'll know you need to improve things.
These users thanked the author Oren Hurvitz for the post (total 8):
Graham MillsMarstol NitelyHandy LowConstance PeregrineSelby EvansAlexina ProctorSerene JewellDot Matrix
User avatar
Marstol Nitely
Posts: 480
Joined: Mon Dec 24, 2012 1:42 am
Has thanked: 1019 times
Been thanked: 432 times

Re: Fixing slow scripts

Post by Marstol Nitely »

Even more great tools coming. That's great!

Thanks for the explanations and the tools. I'm understanding more about how this new tool works.

I've been testing in a world that has no scripts. First with several items and then one at a time. I tested the chandelier with it sitting near the ground right in front of my avatar. Since the chandelier is showing 0 ms with an occasional spike way under 1 ms, for now I think I'm good. I will add some information to my instructions and directions and then reactivate the chandeliers.

Thanks also for everyone's patience.
These users thanked the author Marstol Nitely for the post (total 3):
Alexina ProctorSerene JewellDot Matrix
User avatar
Kayaker Magic
Posts: 354
Joined: Sun Dec 01, 2013 8:40 am
Has thanked: 52 times
Been thanked: 393 times

Re: Puzzling slow script score on surfboards

Post by Kayaker Magic »

Kayaker Magic wrote:I have a bunch of demo surfboards, kayaks and boats lying around on Panthalassa for people to try out. They all get Top Script scores in the 30 to 60ms range when they are sitting around doing nothing. They should be getting 0 (zero)!
Slow but steady progress report:

I found the source of this surfboard problem. The way I implemented surfing has objects like waves, rivers, rip currents, rocks and skywater sending messages occasionally (using llRegionSay) to interested vehicles. And the white water rivers are the same "type" of feature as a rip current. So when the surfboards listen for currents in the ocean, they also get messages from all the rivers. And I have an extensive white water river system on Pahthalassa with dozens of prims, each sending a message twice a minute. (A side effect of this is that you can paddle a surf board upstream in the rivers if you want to, and drift back down).

The surfboards store information about nearby currents in a list. A problem with lists in LSL is that they are immutable, meaning that you cannot change one element of a list. Instead you create a new list with one value different, and you replace the old list with the new one. The entire old list becomes orphaned and is cleaned up by the garbage collector later. Every time a surfboard got a message from a river, it had to store several things about it in lists, which created orphaned lists to be collected. The CPU was probably spending most of it's time in the garbage collector.

I tried optimizing the listen code in the surfboards with the following tricks:
    1. I stopped storing counters that incremented in lists. Instead I stored the time in a list, then just read that and calculated the delta time later. This meant the list of counters was not re-written as often.
    • I checked the values I was storing in some lists, like the position of a river prim. If the position was the same as the value already in the list I skipped updating it. In C this would be like saying if (R!=pos) R=pos; This is silly in C, but in LSL it saves the overhead of re-writing the whole R list.
    • I considered putting a switch in the surfboard dialog to disable listening for currents. Or recommending that surfing and white water kayaking shouldn't be set up in the same world.

I think these changes decreased the average "idle time" on the surfboards to a third of what it was. It is hard to tell because there is still a lot of variability in the Top Script scores. Some of this variability probably comes from the asynchronous arrival of different numbers of messages from rivers in a given 30 second period.

The time the CPU spends in the garbage collector is hidden from Top Scripts. All my extra tests may be increasing my Top Scripts time but decreasing the time the CPU spends in the garbage collector. I look forward to the server statistics Ilan has promised us, this might show that my efforts so far have improved things.
These users thanked the author Kayaker Magic for the post:
Dot Matrix
User avatar
Ghaelen DLareh
Posts: 76
Joined: Thu Dec 27, 2012 4:13 pm
Has thanked: 49 times
Been thanked: 59 times
Contact:

Re: Fixing slow scripts

Post by Ghaelen DLareh »

Kayaker Magic wrote:In my experience, the most common reason for large Top Scripts scores is calling llSleep, llSetPrimitiveParams, llAdjustSoundVolume or ANY OTHER ROUTINE that has a forced delay. If your clock script is using llSetLinkPrimitiveParams to move the hands, change it to llSetLinkPrimitiveParamsFast and I'll bet you see your Top Scripts score go down my at least two orders of magnitude.

Unfortunately, these high scores from forced delays do not actually indicate that your script is using lots of CPU. Ilan verified this for me today when I got the Top Scripts score on my surfing waves to go from 3000 down to 3 ms /30 seconds (THREE ORDERS OF MAGNITUDE!). Ilan looked at the server statistics and my CPU usage did not go down at all, even with this huge drop in Top Script scores. The reason is that the entire time your script is in a forced delay is counted towards top scripts, even though your script is not running and not using the CPU during this time. It is locking up other important resources, so you want to fix this for several other reasons anyway:

1) Ilan will stop beating you about the head and shoulders about how THAT script is using up too much CPU.
2) Your customers will stop beating you about the head and shoulders about your inefficient scripts.
3) Forced delays (or ones done on purpose with llSleep) lock up a "script thread", a very important simulator resource. You do not want to see what happens if the simulator runs out of script threads.

I have written about this forced delay problem before: viewtopic.php?f=26&t=1149

Changing calls from llSetLinkedPrimitiveParams to llSetLinkedPrimitiveParamsFast is easy, working around some of the other functions is more difficult. It is most difficult to switch from using llSleep to using llSetTimerEvents, but I think this should be done.

I have done several optimization passes over the surfing wave script and was puzzled why it continued to get such a high score on Top Scripts. It turned out that I forgot there were 5 little tiny scripts in child prims that made wave hissing and crashing noises. These scripts called llAdjustSoundVolume once a second to make the wave get louder as it approached the beach. I did not realize that llAdjustSoundVolume has a 0.1 second forced delay until today! That is 100ms * 30 seconds * 5 scripts which is a big chunk of bad top scripts score. I re-wrote the script to play a sound that was pre-recorded to increase in volume, then based on a llSetTimerEvent switched to looping a sound at fixed volume, then switched to playing a sound that fades at the end. Fortunately in water hiss sounds, you don't hear a click when you switch from playing one to another.
I know I'm reviving an old thread but this is new to me.

First, is this still an issue?

Second, if it is still an issue, Is there somewhere you can point me to in order to learn how to do make the changes? Or perhaps a library of scripts that have the new elements in them? Our Kitely thread of scripts for doors mostly still have the 'bad' lines of code in them (if they are still 'bad').
A Curative Poison (a metaverse story)

De Landria Rising Market

The De Landria Project
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: Fixing slow scripts

Post by Ilan Tochner »

Hi Ghaelen,

Top Scripts no longer counts time spent in llSleep but all of Kayaker's recommendations are still very relevant for improving your script performance.

What specifically do you wish to know?
Graham Mills
Posts: 1314
Joined: Sun Dec 23, 2012 2:26 pm
Has thanked: 1134 times
Been thanked: 1141 times

Re: Fixing slow scripts

Post by Graham Mills »

If you're working with time-dependent events then llSetTimerEvent and the associated timer event should be useful. Not sure whether it's still the case but I believe the Lumiya viewer for Android ignored llSleep completely.
Post Reply