MONO slowness...

Well... preliminary testing is... not good.

THough it seems to "work" flawlessly so far which is in itself a great feat. It is actually slow. SLOWER than the old interpreter for MOST scripts.

The worst culprit is the "idle script" the one where someone used a script to start a particle effect and left it "running" even though it's not processing any messages or code whatsoever. In MONO those kinds of scritps take up 2.5 times the script time of othe old interpreter.

50 idle scripts in the old LSL engine == 0.137 ms script time
Same 50 idle scripts compiled for mono == 0.321 ms script time

This is almost a show stopper. Why?

Probably 50% of all scripts in a sim are this kind of script. They are in EVERYTHING. plants, water falls, fires... I found about 800 of them on my sim one out of about 1600 scripts total. And they take up quite a bit of time just sitting there doing nothing.

If there was ONE THING I was hoping mono would fix is that it would recognise when code execution had died and STOP polling/monitoring or processing the script. WHen the main code loop ends and there are NO messages in the q, the script interpreter/execution should HALT for that script.

Peak execution times for complex scripts seem to be down maybe by 50% but most scripts are relatively idle and all of them are showing higher script usage time than before.

As a side note, the "mono time" in the script viewer is always 0.000 even for mono scripts. Is this feature not implemented yet? Or is this an indication that maybe mono is not actually being used and somehow the old interpreter is being used instead thus the unbelievable slowness?

So far the Mono rollout has been the single biggest disaster I've ever faced as a content creator, and we (the Combat Samurai Island) team now have more than nineteen thousand customers with horribly broken content.

I have no words for how upset I am.

Oh, just to clarify : The Mono rollout broke *existing* content. Scripts that were supposed to operate as they always had before, not compiled with Mono and therefor running on the 'old' script engine, are suffering performance problems with unacceptable (5+ seconds) delays. These scripts have been working great (in this regard, at least) for 2 years.

When the rollout was being staged, we could see this by visiting sims running on either server version. Older servers continued to operate as expected, whereas newer servers had severe problems. Now that the entire grid is running on the Mono-enabled servers, all of my products are broken.

Backward-compatibility is broken, obviously

My open space sim is a mess! Nearly everything is slow and many items dont work anymore. It is clear there are deep problems. Everything was fine before the server update. I can understand why sl developers can be quite frustrated!

I've just tried the new object return function. It's a nice idea and i like it. I do have a problem with the implied functionality of the "Return only those objects on someone else's land". It seems that this function also returns legitimately placed objects that are on group owned land. This isn't clear and there should be a difference. When i read this "Return only those objects on someone else's land" statement I believed that it wouldn't return these tagged items on group owned land. Perhaps some clarity and some further options in the tool to make it more functional for these cases.

Not to shift blame - I agree with what you've posted, really I do - but I do wish that content creators would get with the program and REMOVE unneeded scripts such as these. So many scripts out there do nothing after the first run - just getting rid of every script that does nothing but call llSetText once would dramatically reduce script time in just about every sim on the grid.

(edited to add: At least now these tiny scripts only take up a tiny amount of memory under Mono instead of a full block of 16kb under LSL2)



I'm /fairly/ sure that this is an unimplemented (yet) feature. Its presence also makes me question the legitimacy of the script time comparison as shown in your experiment. Not your methodology, but it could be that LSL2 VM time and MONO VM time are simply incomparable - apples vs bananas, and the "Mono time" will eventually show a "compensated" time that will give you a better idea of actual impact.

But of course, I could be wrong.

I'm a beginning builder and do have some items for sale now here is one thing to note for
those worried about those scripts that just set some thing and go idle. maybe with the
way the product is built there is going to be some 'idle' scripts. I have a fountain that is
part of a gazebo and there is a particle script in the nozzle prim so that i have a water
'spray' affect coming from the top of the fountain. now i have this in a 'jack-in-the-box'
rezer so that i can put in in a rezing vender now if i have the script self delete the first
time a 'customer' rezed it the script would go poof and any other 'customers' would not
see this 'feature' of the fountain and if any one that bought it rezed it then had to pull
it to there inventory to move location would lose it as well.

Mono can hardly be blamed for bad coding. If people actually learned how to code instead of being a bunch of 'cut and pasters'.

Doesn't anyone use this?:

llSetScriptState("ScriptNameHere", FALSE);

It works wonders, for all your run once, particle/set text needs.

Correct, but it's still a shame that the Mono-enabled server has a flaw regarding so much existing content. The implementation CAN be blamed for making the consequences of a very common mistake even worse.

In any case, it needs a JIRA entry. Farallon , please create and let us know what it is so we can vote for it.

There is already a JIRA entry for the problem RobbyRacoon is experiencing (that code in the state_exit handler runs terribly slowly). It's already assigned, so no need to vote for it. To track it:

http://jira.secondlife.com/browse/SVC-2958

For the record, I recompiled all of our stuff yesterday. Typical script time savings was around 50%. So scripts that were using .004 ms before are using .002 ms now. Most operations seem "snappier".