MONO Script Timing

I have been testing my project under MONO on the BETA grid.

After some initial failures LL have got MONO working (at least as far as I am concerned).
However I am encountering strange timing variations.
My project consists of a large number of prims all talking to each other. Currently using llWhisper on a private channel. To speed the events in the project the user is allowed to interrupt the main script by selecting the required result as soon as it appears. This causes (in the main grid) the scripts to be shortcutted and thus allow the next user their turn earlier.
However on the BETA grid the actions appear to be continuing.
I can only put this down to timing of the events/interrupts not being processed in the order I detected was required on the main grid.

Should there be any difference?

There is no guarantee that a given script in LSL2 will run x% faster under Mono, so anything that relies on an assumption that script X will finish up before script Y is going to need review. Really, overall timing is almost certainly going to be different, just because certain LL functions have fixed artificial delays while user-written code will generally be faster (but LL functions in Mono have different timing even apart from the penalties).

You might need to add some kind of ack to your protocol if things should happen in some kind of order.

Also, never expect messages sent in a specific order to arrive in that order. They will if you get lucky but most times they won't.

Also, instead of relying on whispers you should make use of llRegionSay() as that one is more efficient. (doesn't have to do the range and other checks)

I agree with the first comment and thought I had taken that into account.

The second suggestion is worthy of consideration. Where can I get details of the delays and/or checks that each of the communication functions incurs? I want to consider a newer version of the project and redesign might be beneficial there are many communcations between the up to 135 prims most with multiple scripts embedded.

I have noticed a startling improvement in performance of the object under MONO.

The SL wiki will list the artificial delays for functions that have them up at the top right. Other than that, there really aren't any assurances about anything, not even that a message will get there. You really need to think of it like you would a network application, simply not trusting that the environment will be amenable.

Squirrel Wood mentioned something about range checks which would not have to be done by llRegionSay compared with llWhisper.
Is there a comparable list of checks for all the communication functions?

No real documentation as such, the priority that llRegionSay gets in the listen filters is an implementation detail that happened to be mentioned in a mailing list.
( https://lists.secondlife.com/pipermail/secondlifescripters/2007-November/001993.html )

And it's well established that link messages beat all the chat variations.

A lot of the little tricks people use to squeeze a little more out of LSL may or may not do anything with the switch to Mono, and because the new stuff is no longer compiled on the client there is more of a black box than there was with LSL2. The server side code is supposed to go open source some day, but until that someday event there will be missing information on Mono script timing until a) the Lindens are finished developing it and b) people can get their scripts off to an empty region and try benchmarking without others' stuff running.

And for LSL documentation in general, there is no shortage of sources, but every last one of them is incomplete and has some outdated or erroneous information. (One of the worst is the official PDF that's thrown in with the SL viewer).

Sounds like there is lots of scope for some enterprising coder to do some fundamental research.
Thanks for the link

even under normal LSL. you if output a bunch llOwnerSay they will not always be received in the same order.

theres a lot of queueing going on really fast but with varying speeds..

I am sorry but we are straying from the original thrust of my post which was to elicit some knowledge about MONO and its effect on scripting.

Does anyone have specific knowledge on the subject of MONO?

Everything that has been said applies to MONO also, even though most of it will execute much faster. llSays can still arrive out of order and im's are usually better. And using llRegionsays, instead of llSays etc is better because the simulator doesn't have to process the range data. MONO also treats state changes rather poorly.

As far as testing MONO, YEP, I have done an extensive amount of testing as I am sure most of the regulars have here. But the only way to see is go try it yourself.

Just try basics scripts with loops called multiple times and have them say the time when they are finished. Try it for the different communications methods. Although not perfect due to different contributing factors, such as what all is happening in the sim when the test is run. In an empty sim you can still get some good data and make an educated decision.