Revived JIRA for increase in memory limit

[Profaitchikenz Haiku]

If the amount of memory scripts can have gets doubled, is there not a risk of the return of the dreaded sim-freezing as avatar enter and their scripts get added to the server?

I also think that just doubling the amount of memory a script can have to get around a data issue is overkill, a better data storage method or faster notecard-reads would be an alternative?

[Kyrah Abattoir]

8 minutes ago, Profaitchikenz Haiku said:

If the amount of memory scripts can have gets doubled, is there not a risk of the return of the dreaded sim-freezing as avatar enter and their scripts get added to the server?

I also think that just doubling the amount of memory a script can have to get around a data issue is overkill, a better data storage method or faster notecard-reads would be an alternative?

Notecard reads are async operations with ye ol asset server. Unlikely to get faster unless they do caching.

A lot of language facilities could reduce the memory footprint of scripts. Communication in a linkset is still... not a cheap operation, it's certainly cheaper not to communicate.

[Innula Zenovka]

I have a question about the whole basis of this discussion.   It's a genuine one, since I'm conscious I don't know much about what happens server-side and I may be misunderstanding.

However, I read in the wiki that 

Quote

Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. LSL2 allocates a full 16KB for all scripts, even simple "Hello, Avatar" ones. Mono allocates only the memory it needs.

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

I infer from this, therefore, that the only circumstances in which anyone is going to use > 64KB of memory is if the script actually requires >64KB.    I infer further that there's no particular benefit if, on the comparatively rare occasions the scripter needs (say) 100 KB of memory, that memory is used in two scripts needing 50 KB each or one script needing  100 KB (and using only 100 KB, not 120).    Indeed, the latter would presumably be preferable, since the two 50 KB scripts will contain needless duplication of variables, events and functions, and involve extra overhead in sending and processing messages between the two.

Furthermore, since the only way actually to use >64 KB script memory is to sit down and write a script that needs that much, I think comparisons with priority 4 animations and over-large textures are mistaken.   It's far, far easier to upload a huge texture or to set an animation to an unnecessarily high priority,, after all, than it is to write a script that's going to use 100KB of memory.

So why do we need to charge people and play around with permissions?

Edited February 11, 2019 by Innula Zenovka

[Coffee Pancake]

The memory on mono script is more like a cap, were limited to 64kb and if we need more then we have to use multiple scripts and all the overhead that comes with it - duplication of code, linked message traffic, code to handle passing data back and forth .. look at a fairly ubiquitous multi script project like open collar for example, a LOT of the code is just to handle scripts talking to each other. I would be willing to bet you could fit the entire thing in a single 128kb script

For those who just need more data space (like key storage) this will also negate the need for cpu intensive compression routines. It's a win win really.

 

[Innula Zenovka]

I don't often need more than 64kb but when I do, I'm acutely aware of the extra code I frequently require simply to accommodate the fact I have two scripts doing a job that, ideally, only one script should handle.     

Unless ticking the "I want to have 128 KB available" box means that the script immediately reserves 128 KB, even if it's only the default "Hello Avatar" script, I don't see any particularly obvious potential problems.   

For the reasons I outlined above I -- possibly mistakenly, I admit -- don't think that's how mono scripts behave, so I welcome the idea, but I question the need for special fees and the manipulation of permissions to discourage people from ticking a box that I think should more properly. though not very succinctly, be labelled "let me use as much memory as I need, up to 128 KB,  if I turn out to need it."

Edited February 11, 2019 by Innula Zenovka

[Coffee Pancake]

The only obvious instant gotcha will be all those pesky script counters will now think your scripts are double the size !! Not that they ever accurately showed the actual memory foot print of an avatar, but you know .. snake oil and blaming random other people for none specific lag.

[Qie Niangao]

The only real downside I see is the likelihood of weird implementation bugs that aren't easily detected in advance. I mean, who knows what functions unintentionally depend on the current memory-limited length of strings? Or what's been tacitly assumed about script size during sim-crossings and teleport hand-offs? And all the other stuff we aren't thinking of now, for which the existing regression test suite exercises only 64K?

Maybe nothing will go wrong. Maybe it's a simple matter of changing a constant and recompiling the simulator.

Maybe I could interest you in some shorefront the locals call "Marl a gogo".

[Coffee Pancake]

There is no reason why existing scripts would automatically be changed, especially if the mem limit had to be set in advance or via a script command.

[Qie Niangao]

1 minute ago, CoffeeDujour said:

There is no reason why existing scripts would automatically be changed, especially if the mem limit had to be set in advance or via a script command.

(In case that's in response to my post -- self-centered as that sounds -- I wasn't referring to bugs in existing scripts. I meant it could be unusually challenging to uncover all simulator bugs in handling new scripts > 64K.)

[Wulfie Reanimator]

2 hours ago, Innula Zenovka said:

Unless ticking the "I want to have 128 KB available" box means that the script immediately reserves 128 KB, even if it's only the default "Hello Avatar" script, I don't see any particularly obvious potential problems.   

It is true that Mono scripts only take up as much memory as they need. (5KB used out of 64KB = 5KB) Old LSO scripts would always use a static amount (16KB) of memory.

One real concern is everybody defaulting to 128KB for new scripts, where less would be more than enough.

The downside of Mono's dynamic memory allocation is that during transfer (teleport) between sims, the actual amount of memory being used by the script must be calculated and reallocated by the receiving sim. This process is very slow, and it is what causes that noticeable slow-motion freeze to everything when an avatar enters a sim, especially if they have a lot of scripts (even if none of them use more than 10KB memory).

Doubling the default size of a Mono script could possibly almost double that lag-time.

7 minutes ago, Qie Niangao said:

The only real downside I see is the likelihood of weird implementation bugs that aren't easily detected in advance.

I'm sure if LL was to actually go forward with this idea and increase the overall script memory limit, they would do extensive testing on all of the functions to ensure that they didn't break. (I know, ha-ha, LL changing something without breaking anything. Memes.) Memory limits for things like strings don't really have to change either.

[Qie Niangao]

1 minute ago, Wulfie Reanimator said:

 Memory limits for things like strings don't really have to change either.

Strings are currently only limited by script memory, so... it would be a change for them not to change their max size if script memory doubled. That might be the right thing to do, but it would be another, different thing that might go wrong.

And absolutely, they might catch any bugs with enough testing, but that could be a lot of testing. The project may take more resources than it appears.

[Wulfie Reanimator]

2 minutes ago, Qie Niangao said:

Strings are currently only limited by script memory, so... it would be a change for them not to change their max size if script memory doubled. That might be the right thing to do, but it would be another, different thing that might go wrong.

And absolutely, they might catch any bugs with enough testing, but that could be a lot of testing. The project may take more resources than it appears.

Oh, sorry, I got confused by the myriad of functions that truncate strings (to 1024 usually) and forgot that larger strings can exist. 😋

And you're right, it would be a lot of work, I'm not ignorant to these things. But considering all of the other things LL has brought us, I don't think this exceeds any "viability thresholds."

[Coffee Pancake]

Especially as it would almost certainly get a lot of us involved testing and looking for weirdness .. and unlike everything else, it's not subjective weirdness.

[Innula Zenovka]

28 minutes ago, Wulfie Reanimator said:

It is true that Mono scripts only take up as much memory as they need. (5KB used out of 64KB = 5KB) Old LSO scripts would always use a static amount (16KB) of memory.

One real concern is everybody defaulting to 128KB for new scripts, where less would be more than enough.

The downside of Mono's dynamic memory allocation is that during transfer (teleport) between sims, the actual amount of memory being used by the script must be calculated and reallocated by the receiving sim. This process is very slow, and it is what causes that noticeable slow-motion freeze to everything when an avatar enters a sim, especially if they have a lot of scripts (even if none of them use more than 10KB memory).

Doubling the default size of a Mono script could possibly almost double that lag-time.

I'm sure if LL was to actually go forward with this idea and increase the overall script memory limit, they would do extensive testing on all of the functions to ensure that they didn't break. (I know, ha-ha, LL changing something without breaking anything. Memes.) Memory limits for things like strings don't really have to change either.

I'm still a bit dubious.   I mean, is there any reason to think that a single script using (say) 84 kb would place a greater strain on the simulators during border crossings than 2 scripts using 42 kb each?  Though in fact the two scripts would almost certainly need more than 42 kb to allow for two sets of events and so on, and probably inter-script communication.   And wouldn't there be an advantage to the simulator in having to load one script only rather than two?   The amount of memory used by the single script would be no more than that used by the two smaller ones, and probably less, after all.  

[Estelle Pienaar]

The problem that LL has is making sure that new or not elaborate scripted don't create more lag in the future by putting their 10 lines of code in a 128kb script instead of a 64kb script.

We are discussing if there are solutions to prevent this. I don't think that costs + permission changes are practical. I don't think that premium only is practical. What could be practical is to keep the 64kb standard size. If scriptors want more memory they can write a specific function call. I am sure that only people who really need this feature would then do this. Plus maybe the limitation that only one script in an object or a linkset can be set to 128kb to limit trolling potential.

I think that this is the most simple way to implement this change for LL while keeping misuse low. This approach might be feasible.

[Kyrah Abattoir]

I don't see the problem with gating such afeature to premium accounts, it adds a certain level of accountability which isn't a bad thing to have and we need more reasons for people to go premium.

[Qie Niangao]

3 hours ago, Estelle Pienaar said:

The problem that LL has is making sure that new or not elaborate scripted don't create more lag in the future by putting their 10 lines of code in a 128kb script instead of a 64kb script.

But it doesn't work that way, unless those are some mighty big lines of code. As noted above, a Mono script can only use the memory it needs, regardless if it were to be blessed with a 128K limit.

That said, there are occasions where I'd use that 128K if I had it available even when 64K would obtain only slightly less wonderful results. I recently did an event visitor counter, for example, for which I set capacities safe to the 64K limit that I may have doubled if I'd had the space, even though users might never notice the difference. One thing that would deter me would be if the larger script had double the Land Impact weight -- although it rarely matters, and of course never matters to attached scripts.

Honestly, though, the profligate use of attached scripts makes it seem especially silly to fret over doubling a memory limit they'll never approach. I just got a pair of jeans -- jeans FFS -- with both a no-rez script and a (misconfigured) auto-alpha script, neither of which I can remove* and neither of which would be any worse if 128K were a universal limit. If we're actually concerned with script lag, reining-in the uncontrolled proliferation of scripts in mesh attachments would be a better place to focus attention.

__________
* all because the creator is a no-mod flat-earther despite a stellar reputation in the SL rag trade.

[Innula Zenovka]

6 hours ago, Estelle Pienaar said:

The problem that LL has is making sure that new or not elaborate scripted don't create more lag in the future by putting their 10 lines of code in a 128kb script instead of a 64kb script.

Yes, I know.  But my problem is that, assuming the Wiki is correct when it says that 

Quote

LSL2 allocates a full 16KB for all scripts, even simple "Hello, Avatar" ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, making it far smaller as the overall memory footprint goes.

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

I don't think there should be any difference between the two mono scripts containing 10 lines of code each.     

A mono script that, at the moment, is capable of using up to 64 kb doesn't actually use 64 kb if it's just a simple "Hello Avatar" script.   It uses only the small amount of memory it actually needs.

So why is that going to be any different if the same code is written in a script  that is capable of using up to 124 kb?   It won't require any more memory than the identical code written in a script capable of containing only 64 kb, so why would the simulator allocate any more memory to it?  

There's probably a very good reason why it would allocate all the extra memory unnecessarily, as opposed to "only the memory it needs," but I wish someone would explain it to me why it would do that.

Edited February 12, 2019 by Innula Zenovka

[Gabriele Graves]

2 hours ago, Innula Zenovka said:

There's probably a very good reason why it would allocate all the extra memory unnecessarily, as opposed to "only the memory it needs," but I wish someone would explain it to me why it would do that.

IMO If there truly was a good reason currently then it would be an ideal area for LL to fix because it would be broken by design.

[Qie Niangao]

Quote

[12:29] Qie Niangao: apropos nothing in particular: A scripting forums thread speculates on prospects, pros & cons of 128K script memory limit, perhaps as a Premium benefit, perhaps somehow piggybacked on Experiences. Any chance such a thing might happen someday, or is it just a pipe dream?
[12:30] Meeter: Timecheck : User Group is half over
[12:31] Rex Cronon: if even microsoft decided that an OS needs more than 1mb memory:)
[12:31] Simon Linden: I can give the usual disclaimer about not promising any features and future work Qie, but it's something that is requested and we've discussed it a bunch internally
[12:32] Joe Magarac (animats): Unless scripts move out of the main thread on servers, more script activity seems undesirable.
[12:32] Simon Linden: being a Premium benefit would be great, but then if you drop back to regular things get complicated and bad
[12:32] Qie Niangao: ... and the discussions haven't yet dismissed it totally out-of-hand?
[12:32] Rex Cronon: u run them locally:)
[12:32] Lucy daughter of the Devil (lucia.nightfire): a fair script resource policy still needs to be established, imo, beforehand
[12:32] Joe Magarac (animats): If your script needs to do that much, connect to an external server.
[12:33] Simon Linden: not totally out-of-hand, no .... we realize it's needed.   After all, we're coders too so I know it's frustrating trying to make something interesting and hitting that size limit
[12:33] Lou Netizen: depeends on the project. I've worked on things that rely heavily on external servers, but need a dozen or more scripts just to manage inworld components.
[12:33] Qie Niangao: well, in fact it's a size/processing trade-off, often. Lots of scripts out there burning cycles to share memory across scripts.
[12:34] Simon Linden: Right ... some of them, like group subscribos, end up using scripts as a database
[12:34] Qie Niangao: Thanks Simon. I wasn't expecting it was on anybody's plat at this point.
[12:34] Qie Niangao: *plate
[12:35] Joe Magarac (animats): Maybe divide scripts into two groups - 1) can affect the world, run on main thread, time limited, and 2) can't affect the world, run off main thread, more resources.
[12:35] Simon Linden: script size is a huge factor in region crossings and TP issues, so maybe if we could nail it down to stuff that doesn't move around the grid it would be less scary
[12:35] Simon Linden: (pure speculation and brainstorming)
[12:35] Lou Netizen: oooh
[12:36] Qie Niangao: ah, unattached only, that would actually be a win... uh, well, except for the heavy-HUD builders, I guess
[12:36] Lou Netizen: yeah, there are people who wouldn't benefit from that, but others who cerrtainly would
[12:36] Simon Linden: right, I'm sure HUDs would want it too
[12:36] Qie Niangao: if only there were an attachment tax
[12:36] Simon Linden: so there may be small steps possible there
[12:36] Simon Linden: oh good idea, I'll pass that along Qie!  
[12:37] Qie Niangao: like, if ARCTAN could... like scripts affect LI...
[12:37] Qie Niangao trails off, realizing he has no idea what he's talking about
[12:37] Lou Netizen:
[12:37] Joe Magarac (animats): Depends on the HUD. Helicopter flying hud, group 1. Clothing applier HUD, group 2 if possible.
[12:38] Qie Niangao: oh, if there were a punitive, confiscatory tax on NO-MOD attachments, it would make my day
[12:39] Joe Magarac (animats): Many users would benefit from a clear guide on how to set up an external server to talk to SL. One good wiki article.
[12:40] Simon Linden: That would be good, Joe.   A huge part of that is how/where that external server is hosted (and what tech it runs on).     Does anyone have suggestions on what would be a good example?

[... followed by a wide ranging discussion, generally supportive of making it easier to offload script processing to external servers]

I poked the bear.

At least we're officially beyond the point where we're supposed to assume this can never ever happen because reasons.

[Arduenn Schwartzman]

Thanks for rubbing it in the bear's nose, Qie. I really appreciate it.

[steph Arnott]

On 2/12/2019 at 2:32 PM, Innula Zenovka said:

 In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, making it far smaller as the overall memory footprint goes.

Mono was introduced to stop virtual memory switching which LSL2 did constantly. Mono does not exceed the 64kb allocation per script. A stack heap error will occure. Mono does better only if people who compile the script give out copies of the original inworld compiled script. Also Mono uses the most memory when user are using Windows. Test showed that Linux users use less. This is due to the fact that scripts are also on the clients end.

[Coffee Pancake]

4 hours ago, steph Arnott said:

Mono was introduced to stop virtual memory switching which LSL2 did constantly. Mono does not exceed the 64kb allocation per script. A stack heap error will occure. Mono does better only if people who compile the script give out copies of the original inworld compiled script. Also Mono uses the most memory when user are using Windows. Test showed that Linux users use less. This is due to the fact that scripts are also on the clients end.

No. No. No. That's not how any of this works. 😨

[chibiusa Ling]

29 minutes ago, CoffeeDujour said:

No. No. No. That's not how any of this works. 😨

Your flogging a dead horse trying to correct her. Steph gets all her woo knowledge by gazing into a crystal ball, throwing chicken blood over some bones and hoping for the best.

[Kyrah Abattoir]

10 hours ago, steph Arnott said:

Mono was introduced to stop virtual memory switching which LSL2 did constantly. Mono does not exceed the 64kb allocation per script. A stack heap error will occure. Mono does better only if people who compile the script give out copies of the original inworld compiled script. Also Mono uses the most memory when user are using Windows. Test showed that Linux users use less. This is due to the fact that scripts are also on the clients end.

Oh my god, why do you never stop talking nonsense...