You are at 255740.8, 255335.9, 21.0 in Sandbox Goguen MONO located at sim3017.aditi.lindenlab.com (216.82.2.23:13002)
Second Life Beta Server 1.24.4.93464

=======

Look at the comparison between LSL and Mono:

[9:01] SVC-2746 LSL: 0.022235 seconds/state-change
[9:01] SVC-2746 Mono: 0.022235 seconds/state-change
[9:01] SVC-2746 LSL: 0.022238 seconds/state-change
[9:01] SVC-2746 Mono: 0.022233 seconds/state-change
[9:01] SVC-2746 LSL: 0.022860 seconds/state-change
[9:01] SVC-2746 Mono: 0.022233 seconds/state-change
[9:01] SVC-2746 LSL: 0.022240 seconds/state-change
[9:01] SVC-2746 Mono: 0.022236 seconds/state-change
[9:01] SVC-2746 LSL: 0.022234 seconds/state-change
[9:02] SVC-2746 Mono: 0.022238 seconds/state-change
[9:02] SVC-2746 LSL: 0.022237 seconds/state-change
[9:02] SVC-2746 Mono: 0.022237 seconds/state-change

The results are identical and very constant.

========

There seems to be a built-in delay, look at the results from this script:

default
{
state_entry()

}
state state1
{
state_entry()

}

[9:37] SVC-2746 Mono: 0.021857 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.022306 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.021260 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.021777 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.021554 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.021870 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.021511 seconds/single-state-change
[9:37] SVC-2746 Mono: 0.021274 seconds/single-state-change

Again we see very constant results.

This is the output of Haravikk's script on the main grid:

[12:15] Object: 0.000223 seconds/state-change
[12:15] Object: 0.000218 seconds/state-change
[12:15] Object: 0.000221 seconds/state-change
[12:15] Object: 0.000218 seconds/state-change
[12:15] Object: 0.000226 seconds/state-change
[12:15] Object: 0.000219 seconds/state-change
[12:15] Object: 0.000224 seconds/state-change

Indeed, there's a factor 100 between the servers.

=======

The single-state-change script gives this output on the main grid:

[12:25] Object: 0.000000 seconds/single-state-change
[12:25] Object: 0.000000 seconds/single-state-change
[12:25] Object: 0.000000 seconds/single-state-change
[12:25] Object: 0.000000 seconds/single-state-change
[12:25] Object: 0.000000 seconds/single-state-change
[12:25] Object: 0.000000 seconds/single-state-change

Ummm ...

=======

Here's a different way of measuring:

float seconds;
integer counter;
default
{
state_entry()
{ // wait for the seconds to change
seconds = llGetWallclock();
while (seconds == llGetWallclock())

seconds = llGetWallclock();
state state1;
}
}
state state1
{
state_entry()

}
state state2 {
state_entry()
{
if (seconds != llGetWallclock())

else state state1;
}
}

[12:47] agni: 0.001269
[12:47] agni: 0.001267
[12:47] agni: 0.001351
[12:47] agni: 0.001256
[12:47] agni: 0.001401
[12:47] agni: 0.001311
[12:48] agni: 0.001267

LSL:
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478

Mono:
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478
[12:52] aditi: 0.043478

A factor of 33
The aditi results are absolutely constant. This can't be due to slower hardware.
[This way of measuring uses an integer. It only counts to 23 on aditi, so that explains why it is so constant.]

As I understand it, the engine running legacy LSL scripts has actually changed slightly, to dynamically adjust memory, and possibly a few other things, meaning it is more in-line with the Mono engine's behaviour despite still being an interpreted engine. I'm assuming one of these changes must be the cause of the far slower state changes.

This has me concerned though, as I've been using states heavily to write a parser, as they're not only much easier to develop, but were more efficient as it means I don't need a huge if statement tree just to keep track of state as I look at each character of the input. Slower state-changes will significantly reduce the performance of my script in-spite of the other Mono speed improvements.

Try this modification to Haravikk's script:

llOwnerSay((string)(time * llGetRegionFPS()) + " seconds/state-change*sim_FPS");

The output looks like this (while the sim's FPS is varying from 20 to 45):

[13:24] Object: 1.082572 seconds/state-change*sim_FPS
[13:25] Object: 1.057073 seconds/state-change*sim_FPS
[13:25] Object: 1.200339 seconds/state-change*sim_FPS
[13:25] Object: 0.776695 seconds/state-change*sim_FPS
[13:25] Gellan Glenelg: LOL
[13:25] Object: 1.328234 seconds/state-change*sim_FPS
[13:25] Object: 0.887612 seconds/state-change*sim_FPS
[13:25] Object: 1.180765 seconds/state-change*sim_FPS

All values are fairly close to 1.

If state changes are clamped, then scripters will resort to heavier use of globals, which will result in more buggy code and as a result fewer rich LSL applications.

The VM should support the best use of language (as does the LSL2 VM) not limit its use and expressiveness owing to the limitations of the underlying platform.