Faster Mono?

Does anyone have a link, or tips, on getting the most out of Mono?

As in scripting style, mannor etc?

It is easier to make a working script fast than it is to make a fast script work.

/me points at the answer.

The way to get the most out of Mono is to use it for very small, very large, or computationally intensive static scripts that don't move from sim to sim... and avoid using Mono on HUDs and vehicles because of its impact on sim crossings and teleports.

Ouch.

Would you elaborate on that?

Holy Mother Mary. I don't know which is worse: the issue itself or the fact I voted for it already. I haven't the foggiest recollection of doing that.

Maybe my brain is running Mono. I recall feeling a little faint as I crossed into the neighbouring county last week.

Avoid declaring functions as they eat up memory really quickly in many cases. If your script(s) use a lot of function calls such as for list-manipulation, then you may see little difference in speed when moving to Mono, but if you do a lot of calculation then Mono will provide a fairly significant boost.

So avoid functions anywhere you can, and use Mono's greater memory to cache things you need frequently, and use it for scripts that do a lot of computation.

was the issue with slow state changes in mono ever resolved?

It's more that it was kind of documented in office hours. A state change in LSL-Mono gets you an automatic minimal yield (sleep), so your script naps for at least one sim frame.

it's not nearly as bad as it was at first, but I think they are still slower than LSO state changes (although state exit loops are blazing fast if they still work)

/me votes for making the logic of your code flow smoothly and ignoring any mystical tweaks. That and I still make stuff mono because I know I'm going to be too lazy to recompile everything later, once LL fixes that stupid bug.

I am not sure that the startup overhead is ever going to be fixed. It's an inherently difficult problem.

And for most stuff, there's really no benefit to using Mono. LSL2 is fast enough.

mono's good for math heavy, and memory(storage) heavy scripts, bad for sim crossings and fast state changes. oh and it has utf support that LSO doesn't. I don't remember if list manipulation is a bit slower in mono still.

I avoid mono for vehicles and attachments, or huds that aren't math/memory intensive. everything else, I go with mono.

ETA:
temp rez items get LSO

SVC-3895 cannot stay around forever. Their product is crap until it gets fixed.

When I say "it's an inherently difficult problem" I mean that in the mathematical sense. It would require a deep redesign of Mono itself to bring the startup overhead of Mono down into the same ballpark as the startup overhead of LSL2. The best that Linden Lab can do is to mitigate the problem. Replacing the bytecode verifier will reduce the overhead by maybe several times (so you're looking at three seconds instead of thirty seconds). Multithreading the rezzing process will hide the impact on the sim, but it will not make the actual teleport or sim crossing complete any faster... instead of lagging everyone on the sim for 30 seconds, you'll just be lagging yourself.

Using Mono for attached scripts is like writing flash applets for rollovers in web pages, because "Activescript is faster than Javascript". It's not something that's ever going to be a net win for most attached scripts, because most scripts are nowhere near compute bound.

Yes, there was initially a HUGE penalty for state changes in certain cases, which was fixed. By HUGE, I mean, scripts that ran fine in LSL took minutes to run in Mono. IIRC, it was a problem with certain functions used in state_exit handlers.

+1

As a wise man once told me: Optimize algorithms, not code. Optimize code only when necessary, and it rarely is.

I've worked in event-driven software (including real time control and networking) for 3 decades now, and that advice is still the best.

In our case, most scripts do very little, and the Mono speed advantage is meaningless, being overwhelmed by the amount of CPU time it takes to simply invoke the next active script. Even scripts that do nothing at all, with no events queued, take 2 microseconds per "pass". That may not seem like much, but it adds up pretty fast due to the number of scripts.

Most scripts (especially well-designed ones) rarely have anything to do at all. A few extra microseconds to do LSL versus Mono in the rare cases where it has something to do is pretty meaningless.

The thing to focus on is to COUNT how many times a given line of code will execute.

Is it once per click or menu selection? These things are very rare!

Is it once per some timer firing? If the timer is long, then it's no worries.

Is it running all the time, or with a short timer? EEK! Redesign it if possible!

How many of these scripts tend to be running at the same time in a given region? Multiply the answers above accordingly.

It's all in the numbers. Anything that happens less than once every few minutes is meaningless, as long as the response time is reasonable.

it's always helpful to know some of the major themes though, especially if you have two competing runtimes.... that isn't to say that code that works in one won't work at all in another (with a few exceptions) but if you have an option, you may as well go with what fits the generalities best (micro optimizations are really a different topic)

When we eventually get global script limits, and suitable functions, it should be possible to write the code for an entire object in a single Mono script, rather than requiring lots of scripts with messaging protocols scattered all over the place, which should hopefully reduce the size of any scripting project done in Mono.

Mutli-threading of the Mono start-up process, and some way to cut back on validation (e.g - only validate scripts that aren't correctly versioned or signed) is still desperately needed. While it's understandable that Mono by its very nature requires a bit more work than LSO-LSL to start-up, it really should be as lean as possible, and the fact it halts the entire sim is pretty ridiculous.

Flash wouldn't be faster in that sense, and it's Actionscript.