Increase mono script memory cap
tracked
Xaviens Mizin
The existing mono memory cap of 64kb per script is based on simulator hardware that is no longer in use. The 64k limit is regularly subject to workarounds by use of 'slave' scripts to hold on to memory, at excessive cost to performance, from having multiple scripts doing the job of one, resulting in a net loss of performance versus a single script with increased memory. Is there any possibility that this could be increased, even slightly?
Log In
observeur Resident
that's great news :)
Spidey Linden
tracked
Spidey Linden
closed
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
rhet0rica Resident
As an aside, this seems like it might be a pretty big ask if they're generating Mono code that only has an 8-bit addressing space. I suspect that's part of why 64 kb was chosen in the first place, rather than 32 or 128.
observeur Resident
I was going to write the same feature request. As Xaviens said, the main problem with this 64kb cap is that we have to make 2 or 3 scripts to do the job of one, with the complications related to the way scripts communicate with each other using asynchronous messages, and because we lack of the possibility to create simple functions libraries (that could be the object of a separate feature request). I believe it would actually make things easier and lighter on the server side as well.
Kristy Aurelia
While more memory would be great, I would like to see the underlying issues addressed - LSL's poor memory efficiency:
• Global variable names taking up memory for each character in the name
• All the various hacks that are used to save memory by the LSL Optimizer: http://lsl.blacktulip-virtual.com/lsl-pyoptimizer/
• Any other optimizations that compilers do for other languages.
I should probably make this as a separate suggestion, but it is worth noting in this topic.
Xaviens Mizin
Kristy Aurelia: I hadn't heard of some of these. I just tried all of them across a few different scripts, and saw no changes from llGetUsedMemory, with the exception of using pre-calculated values when the result is always the same. It's possible these some of these issues are already gone.
Kristy Aurelia
Xaviens Mizin: Scripts tend to allocate memory in 512 byte chunks, if you don't cross over the next boudnary, the reported usage will stay the same.
For example, after running the LSL Optimizer on AVSitA:
Memory Used ([AV]sitA): 60262 (5274 8% Remaining).
Memory Used ([AV]sitA_Opt): 51286 (14250 21% Remaining).
So there are plenty of optimizations that the server could do when compiling the code.
Anyway, as I've mention more memory - always good, things using less memory is also good, especially if I don't need to manually work to make it use less.
Vincent Nacon
Lindens has mentioned on Discord that they're making the transition to 64bit version of the server build. They don't want to rush it and ensure everything is covered to prevent memory leaks and other issues. After this, they can look into expanding the script memory. 🤞
Keen Voxel
I would imagine they would have to double it at the very least to keep scripts from involuntarily stack-heaping when the default integer changes from integer to long (unless they just add support for long/double in script straight out the gate)