Mono and attachments: always, sometimes or never?

When I first discovered that a script I was working on would run out of memory while creating a particularly large list from data on a notecard, I found that compiling it for Mono not only solved the memory shortage problem, but also speeded up the notecard-reading process considerably. Since then I've been routinely compiling my scripts for Mono.

I am now aware of the sim crossing issues associated with Mono-compiled scripts, so I've been routinely recompiling my attachment scripts for LSL. However I do have some scripts that will not recompile like this, and which would take some effort to redesign for use under LSL. Also, doing so would add to the complexity of the inter-script communications, and to the data storage cost because several variables and constants would need to be duplicated across the scripts.

Are there formal guidelines, or even rules of thumb, I can use to try to determine when using a Mono-compiled script might be preferable to using (an) LSL-compiled one(s) for attachments?

And are there any reasons why I should not always use Mono for scripts that do not routinely cross sim boudaries?

heyas;

i don't think there are any formal guidelines (who would make them formal? :D ), but i'm glad you're cognizant of this problem.

anything that rezzes a lot should be, whenever possible, compiled in regular lsl. ESPECIALLY attachments. probably also bullets/ammo.

anything you set out and leave there, should be fine with mono scripting. as far as i know. its some sort of mono loading 'feature' that causes the slowdown. once the mono script is running, it is fine.


now, of course, you can't always do this. there's the memory considerations, as you found out. if you just CANT fit a script into regular lsl, even an attachement, then go ahead and use mono.

eventually... well, we can hope... this 'mono rezzing lag' bug will be fixed. (there is a jira on it, if you want to vote for it. gah, i dont have the link on me. im me in world if you need it.) as long as you're not contributing to it by making a 150 prim hairstyle with resize scripts in everysinglemotherlovingfreeking prim that are all mono... :X i'd say you are doing your part to reduce lag on the grid.

/me would continue to use mono. They'll fix, eventually, some day, hopefully, the current problems.

I think it's not a problem to have a couple mono-compiled scripts in attachments. But if you had a script-resiable 200-prim hair with mono scripts ... eep!

I have two small HUDs I made that are both mono and have never noticed a problem. I suspect that the issue is more for scripts that have to keep working, or start working again ASAP after the TP, such as for vehicles.

My AO is Mono, and seems to work fine. Yeah, I might newbie walk for a moment right after a TP.

I do not believe it is even theoretically possible to make Mono startup anywhere as near as efficient as LSL startup without completely rewriting the Mono runtime. When they announced the Mono project, I thought this problem would turn out to be a critical bottleneck: some of you might remember me commenting that Babbage never flew past a sim boundary during his original Mono demo video. I was wrong about that, and they have done an incredible job making Mono scripts capable of being migrated at runtime. They may be able to improve things a bit, but I don't think they'll ever make Mono scripts anywhere near as fast to start up as LSL ones.

Mono is just-in-time translated into machine code. That's what makes it that fast. This means that when a Mono script is run it is translated from Mono bytecode to x86 machine code. This is not as expensive as recompilation, but it isn't exactly trivial either. Then the associated data structures need to be unpacked from a similarly tokenized format... each list needs to be traversed and allocated, each string copied to a newly allocated buffer, and so on.

LSL is tokenized bytecode. To start up an LSL script a 16k chunk of data is read from a file or from the asset server. That's it. Done.

They could probably cache and transmit the result of that JIT compiling, and keep enough meta-data around to invalidate the cache when necessary. That can't normally be done with Mono bytecode, but LL's servers are most likely similar enough that it would save a lot of work a lot of the time.

That would mean it would need to, at the very least, be position-independent code, which would reduce the performance of the Mono interpreter. And it would still leave the Mono start up time much higher than the LSL start up time, because you would still have to serialize and deserialize the data structures.