What's MONO Good For? What's MONO Bad For?

I'm wondering indeed exactly what "mono time" is and why it is uniformly zeroes. I'm hoping (faintly) that you are right that the estate tools aren't showing correct values somehow.

I also noticeed that the top script list no longer reports the object locations which is a big PITA.

I took this to mean that unless you specifically choose to 'opt in' then nothing changes. Is this not the case?

Robby -- this is an obvious and nasty bug related to state_exit handling --- see (and vote on)...

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

...it affects LSL compiled scripts

yeah that -- I'm not sure how, but I failed to notice that column was blank. Big PITA is a bit of an understatement.... time to go nosing about in the JIRA.

I'm also encountering an inability to scroll in the all-search pages... I think I've heard of people having problems w/ that in the current released viewer, but I hadn't seen it before. Not to mention some less-than-stable behavior. This *IS* a brand-spanking new RC... I have faith it will get better before it hits the streets as an official release. Like I said, I'm off to actually read the release notes for the RC and start perusing the JIRA...

While you are in Jira - vote for this one
http://jira.secondlife.com/browse/SVC-2967

See JIRA issue VWR-8606 (http://jira.secondlife.com/browse/VWR-8606).

Havok 1 used to crash sims and work "fine" too

In general, you should compile your scripts to mono, because it will end up using less memory on the server.

With old LSL compiler, every script takes 16K of memory.

With Mono, ever copy of the same script (same asset UUID) shares the same code page, and gets memory allocated to it as it's needed.

So, unless you have a specific reason not to compile to Mono, you should use Mono by default.

Hey! If you do this, please note your simulator script time in ctrl-shit-1 before and after doing the recompilation of your scripts. I'd be fascinated to know the results of taking an LSL sim and recompiling alll scripts to Mono.

/esc

I'm not sure this is actually true anymore, iirc LSO-LSL scripts now scale memory as well. There are several changes which were made to LSO-LSL despite assurances that it would remain unchanged, including some weird throttling of states:
http://jira.secondlife.com/browse/SVC-2750

Did a few more to test function execution speed

// Speed of Frand execution (5 runs)
default
{
touch_start(integer total_number)
{
float time = 0.0;
float _time = 0.0;
integer i = 0;
float random = 0.0;

for(i = 0; i < 1000; ++i)
{
_time = llGetTime();
random = llFrand(30.0)+30.0;
time += llGetTime()-_time;
}

time = time/1000.0;
llOwnerSay("LSL: "+(string)time);
}
}

[5:21] Object: Mono: 0.000178
[5:21] Object: Mono: 0.000042
[5:21] Object: Mono: 0.000070
[5:21] Object: Mono: 0.000025
[5:22] Object: Mono: 0.000067

[5:23] Object: LSL: 0.001349
[5:23] Object: LSL: 0.001198
[5:23] Object: LSL: 0.001373
[5:23] Object: LSL: 0.001284
[5:23] Object: LSL: 0.001207


// Same test with llGetLocalPos()

[5:27] Object: Mono: 0.000144
[5:27] Object: Mono: 0.000134
[5:27] Object: Mono: 0.000091
[5:28] Object: Mono: 0.000068
[5:28] Object: Mono: 0.000098

[5:26] Object: LSL: 0.001192
[5:26] Object: LSL: 0.000981
[5:26] Object: LSL: 0.000977
[5:26] Object: LSL: 0.000967
[5:26] Object: LSL: 0.001266

// Same test with llListFindList()

[5:37] Object: Mono: 0.001687
[5:37] Object: Mono: 0.001574
[5:37] Object: Mono: 0.001649
[5:37] Object: Mono: 0.001510
[5:37] Object: Mono: 0.001597

[5:38] Object: LSL: 0.003307
[5:38] Object: LSL: 0.003155
[5:38] Object: LSL: 0.002780
[5:38] Object: LSL: 0.002584
[5:38] Object: LSL: 0.002872

Looks great, so I do hope that the estate tools are off

wow.

great, thanks guys. :) im getting the feeling, though, that we don't know what it's good/bad for yet, until all the kinks are worked out.


so... let me get this straight. from a simple kindergarten-level scripter here...

scripts with timers-- still take up script time and still cause lag with mono. and shorter timer times lag more. right?

listeners-- still parse input and cause lag with mono, same as always. no?

setpos/rot/parms-- still throttled to delay 0.2 seconds every time you do this. yep.


these are the main things i work with. and yeah, the detect the spot that got touched function is really cool. but i was told that it only works if people clicking the thing have a mono-enabled client. which, btw, not everybody has yet. ;P

Right, but when used reasonably aren't a big problem, even less of a problem compiled to Mono because the Mono handler will run faster.

Same as always, but with less of a penalty for having the *script* parse the input rather than letting the sim do it (by restrincting, e.g., owner-only, in llListen() call). Still a good idea to restrict appropriately!

All delays still apply. Furthermore, it's a good idea to avoid trying to get around these delays. Things that are delayed are delayed *because* they cause lag; they're delayed to discourage you from overdoing them. When coding tricks to avoid delays, be sure that it happens rarely!

Just to clarify, the first part would still be true (it can end up using less memory on the server) even if the second part is false (every LSL-compiled script takes 16K of memory), because of code segment sharing for Mono-compiled scripts.

I'd be surprised but happy to learn that dynamic memory allocation was retrofitted to LSL-compiled code. Please let us know if you can point to any authoratitive info on it.

Right. And I'd be willing to bet that most scripts out there use less than 4kB of memory (how many do we have just to set a simple particle effect, float text, animated texture, convert a chat message into a link message, etc.?), so even if the amount of memory they use is worst-case multiplied by four, I suspect sims are likely to save memory on average (if x<4kB then 4x<16kB).

Mono is OK to play with for personal use, but it is not ready for objects to be sent out into the wild, unless the scripts are open so that end users can recompile after the runtime blows up.

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