Mono's memory space

I was just on the beta grid to test out mono. I had read conflicting things about memory allocation in mono. Some places say it will be allocated dynamically as needed, other say the usual 16K memory limit will remain.

Anyway, I compiled my script in a mono region with mono enabled and not. Without mono a key memory test showed 3401 bytes free, exactly the same as I get on the main grid. Compiling under mono, the same memory test reports 19,887!!!!! Clearly the 16K limit is not being imposed in this version.

So what have people heard. Will we have more memory to work with under mono?

In the mono chat they said that memory limit is 64K and yes, the memory would be allocated dynamically.

https://wiki.secondlife.com/wiki/Mono

in mono script memory is allowed to 64K as scripts get memory dynamicly unlike now every script gets 16K used or unused and there alot more smaller scripts out there and i think most memory heavy scripts need more memory in intervals when they`re active

which will translate to Mono scripts getting as much memory as they need up to a hard cap of 64k (which should be enough for anyone right bill?) the cap is what freemeory will repot on, even though the scripts will no long reserve all of the available free memory

The 64k script limit is the thing I look forward to most with Mono. More than the speed bump and promise of proper language support further down the road. The headaches I've had in the past trying to optimize the crap out of code to squeeze into 16k and/or spread across multiple scripts! So this'll help reduce the number of scripts needed and therefore make it less laggy. But one of the other reasons I sometimes create extra scripts is for more timer events. Multiple timers per script (without resorting to trickery with a single timer) would go nicely with the 64k scripts.

So.. My old class 4 mainland home that's already overloaded with scripts is actually going to get _more_ sluggish with MONO as each script starts to use 4x as much memory as it used to?

Or will things that use the old VM still only eat 16k?

Two comments:
- Memory usage is not the main cause of lag
- Mono uses memory dynamically, so a script, that t.ex. only sets the floating text of a prim wont use 16k as with the old system or the maximum of 64k, but rather the 0.5k it really needs. So I would expect overall memory usage to drop rather than rise.

I believe in Mono characters occupy 16 bits, where in LSL they occupy only 8. So a script with a lot of literal strings will need a lot more memory in Mono than in LSL.

mmmmmmmmmm 64k sounds soooooo yummy!! (hehe remembering an old bit on mst3k when joel was quizzing the bots for tasty ramchips) can't wait!!

no as described by LL old scripts chew up 16k whether they need it or not, mono scripts will chew up what they need and no more than 64k.... overall it should reduce the amount of VM memory needed... at least in the short term untill people start using that larger limit.

Plus the fact that MONO will process the data during each simulator slice much more efficiently and faster in the majority of cases.

That is, if/when those tiny ultra-common scripts get re-compiled to mono, as I believe it's been stated that existing lsl scripts won't (or can't) be automatically upgraded to mono.

Assuming people realize that they can have more little scripts in a sim, it's possible for a larger number of little scripts to cause more lag as the server has more to poll during each slice, even if it is a little faster than the current VM. Hopefully the balance is such that it's still the same, or faster.

If you bother yourself to log onto the beta grid and actually test your scripts on mono you will find that they do not only execut a 'little' faster but a whole f***ing LOT faster. That is, unless they use functions that cause the script to sleep for a certain time.

Either way anything involving maths is going to be FAST.

I thought this tidbit was interesting:

I already did my tests and made a good deal of explosions as well, that have been fixed since then. The speed gains were minor, although helpful, maybe 4 to 5 times faster at the most, for a decent basket of normal script operations that aren't pure math. So, yes, that's 'a little' faster.

The point I was trying to make is that having less memory usage per script will likely mean more scripts per sim, and thus possibly more time spent polling by the sim.

string and list handling is omproved too, but a few things like state changes seem to have actually slowed down... so definitely check your scripts, so you don't get any nasty surprises.