Where did all the Mono memory go?

I am trying to collapse two LSL scripts in one object into one mono script. Each script alone ran under the 16K limit. When I recompiled the first script under mono, it reported a llGetFreeMemory of something like 61000 which is what I would expect. When I finished moving everything from the second script into the first I started getting stack heap collisions. I took out some code and did a quick llGetFreeMemory and I was down to 1850! How does a script that takes under 16K end up blowing the memory?

Has anyone else encountered this?

Programs compiled with Mono can use more memory than they did with the old compiler. That's why they needed to allocate more memory.

Beyond that you'll need advice from someone other than me.

Yep. That's clearly it. It looks like I'll have to continue using 2 scripts. That's a bummer.

I would'nt give up on it yet. Wait a couple of weeks for some bugs to be worked out and try it again. Might even take up to a month for everything to be working really smooth.

Possibly there's a way to modify the scripts to better match Mono's memory usage.

well this is funny...

my old billboard uses 6.922852 KiB memory running

ticked the "mono" box, reset the scripts just to be sure

28.515630 KiB of memory used


err...

I'll do that. One of the scripts has a half dozen states. I'm wondering if that causes the problem.

But I thought that mono was going to save sim resources. This looks like it is taking over double the memory. That would look to me like an increase use of system resources. I guess it's easier to beef up a sim's RAM than it is to speed up the processor.

Well state switches are definitely screwed right now in MONO. I would expect this to be the highest priority bug when LL comes back to work.

either that or the memory functions are out of wack when using mono

don`t see the same script use 4* the memory and the script i`ve just tested has no states but default and a dozen of "if"`s...

If I recall correctly there is a trick in wide use in old LSL scripts to minimize use of memory in list operations that sort of works the opposite when compiled with Mono.

crackers if that`s true...

That's interesting to know. However, these memory estimates are coming right from state_entry in the default state, before anything starts running.

And even if the llGetFreeMemory is borked, I'm still getting stack-heap collision right at startup. So I've definitely run out of memory.

having a look at the free memory i made a lil discovery

integer Ki = 1024; // 1024 == (1 << 10);
float maxPerScript = 16 * Ki;
llSay(0, "LINK_TERM: " +(string) ((maxPerScript - llGetFreeMemory())/Ki) + " KiB of memory used");

ofcourse 16 is with lsl and 64 with mono, so after changing it to what it *supposed* to be it, memory usage is down to: 20.005860 KiB of memory used
still most of the script stores it`s vars in a list tho

still way more then bargined for but less then my previous post

http://wiki.secondlife.com/wiki/Mono#Mono_benefits

This statement seems to suggest that we shouldn't *expect* any memory advantage at all. It's clearly stated that the reason for the increase is not because of better memory management under Mono but bytecode bloat of existing scripts. So we should treat any memory overhead we get as a bonus.

My clear and considered opinion on all this is... "Oh... for crap's sake".

/esc

postscript: I'm pretty sure the wiki statement has changed somewhere along the line since I first read it...

Well - in my experience, MONO improved the usage of lists vastly. I have some stuff that's using lists pretty extensively and with MONO I can store like 4* the amount of data than before. So I think the memory usage really depends on what your code does...

Same here, I have a radio script that stored about 20 stations (before crashing) in a search able list, since recompile I have doubled the amount and according to the llGetFreeMemory function I should be able to store a couple of hundred. I have no need to do so at this stage but was impressed at both the extra capacity and the performance increase (It creates the menu by searching the list).