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
Gwyneth Llewelyn
What about the KVP store? It gives you an extra 64Kbps of unencumbered memory to store whatever you wish...
Pazako Karu
Gwyneth Llewelyn This was bumped to 128kb actually
Nelson Jenkins
Gwyneth Llewelyn Doesn't really help if you are already hitting 64kB in code alone. It's really challenging to write readable, safe code for larger projects that actually make use of linkset data in clever ways. I'd do just about anything for even 128kB.
scriptorus 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.
Darling Brody
Spidey Linden I'm old enough to remember when we were promised the ability to increase a scripts memory using the same command that we can currently use to decrease it. Adding memory to a script was to act as if extra scripts are in the object for the purpose of calculating its Land Impact (prim count). Sadly we have lost many of the Lindens who were coding SL back then so the promise has been left unfulfilled.
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.
scriptorus 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)
Gwyneth Llewelyn
Vincent Nacon I'm almost scared about what that means if, in the near future, they allow, say, 2 MBytes per script :)
Boom, goodbye simulator servers and your 50,000 running scripts...
Granted, many of those only exist because there is so little memory available in the first place.
On the other hand, we all know that
software expands to consume all available memory
(also known as Parkinson's Law applied to software engineering), so in a year or two we would see complaints about how "2 MBytes of RAM is nothing!" and comparing LSL scripts with its 2 MbByte-memory-limit to the memory limit of the JavaScript environment inside Chromium browsers, which is (currently) around 300 MBytes or so...Vincent Nacon
Gwyneth Llewelyn Signal Linden gave more information about the LUA scripting recently. It's running on server side instead of client side as we assumed at first. The deal is, they're compiling script to LUA to cut down memory hog and speed up the performance. It's using UTF-8 for string instead of UTF-16 for example.
More information found here. https://wiki.secondlife.com/wiki/Lua_FAQ