Scripts and sim performance question

[Tonk Tomcat]

Let's say you have 2 scripts, one bigger one and a small one with a listen handle. What's the best way to use as less sim ressources as possible?

• Merge both scripts into one
• Let the small script control the bigger script (llSetScriptState) so you only have one script running all the time?
• Or have different script states within the script, but still merge both of them

[Coffee Pancake]

18 minutes ago, Tonk Tomcat said:

• Merge both scripts into one

Bingo.

[Tonk Tomcat]

17 minutes ago, Coffee Pancake said:

Bingo.

Thanks That's also what my first idea was, i just wanted to be on the safe side

Edited October 29, 2021 by Tonk Tomcat

[Ariu Arai]

Less scripts is usually better, but not always. It's possible to have one script that causes more lag than 50 scripts. It depends on what the script is doing. Fast timers, lots of loops,  SetParam calls, listeners, etc., can cause high script time. Regardless of how much the script does, they all cause a small lag spike when they're rezzed. This is because the sim has to JIT compile each script on rez or when the wearer teleports into a sim.

In summary. Script time is just as important as the number of scripts and memory usage.

[Tonk Tomcat]

So, currently it is like this:

[2/2] running scripts, 83 KB allowed memory size limit, 0.001413 ms of CPU time consumed.

 

When i would change the thing to have the small script just be the listener and switching the other one on/off as needed, it would be:

[1/2] running scripts, 83 KB allowed memory size limit, 0.000706 ms of CPU time consumed.

 

I'm working on merging both into a single one right now. I'd guess the memory usage will not change dramatically, probably the cpu time will be the same as when you turn one off(?) but the rezzing spike for 2 scripts should reduce to 1 then, so i think even tho it's just a small improvement, it's still an improvement, right?

[Qie Niangao]

8 minutes ago, Ariu Arai said:

Script time is just as important as the number of scripts and memory usage.

At least with the current scheduler, script count itself affects script time, even if the scripts have only a single, long since defunct state_entry handler.

Given the stated scenario, I'm having a hard time imagining how multiple scripts could win. If the "bigger script" could be suspended by the smaller one, that must be while it's not doing anything, so there'd be no script time saved, but when both scripts are active the second would add to that scheduler overhead, plus the inter-script communications overhead, all in addition to whatever useful computing is involved.

I'm a little puzzled, however, by the "separate script states" mentioned in the OP. LSL states aren't always the right approach but maybe there are intervals when llListenControl() could win; it's just not clear without more details of the application.

[Tonk Tomcat]

2 minutes ago, Qie Niangao said:

it's just not clear without more details of the application.

So technically those scripts are in an item that listen to HUD commands. The "smaller" one has the listen handle in there and pass informations over to the second one if needed to run some functions then.

[Qie Niangao]

Just now, Tonk Tomcat said:

So technically those scripts are in an item that listen to HUD commands. The "smaller" one has the listen handle in there and pass informations over to the second one if needed to run some functions then.

Right, so as I understand it the listen must be active all the time, hence no role for llListenControl()—nor LSL script states, really, given that they flush listens at every state change.

[Tonk Tomcat]

Alright, so merging everything to a single script is the way to go to have best performance/memory usage in this case.