How would you like the feature to work?

(Oz told me it was ok to make a new JIRA post about this)

Allow users to select a higher memory cap through a drop down on compile time. I suggest a 16/32/64 etc cap, with the highest option preferably not lower than 256k.

Being able to select a memory limit above 64k could be limited to premium users. I for one would finally get a premium account if this was added.

Why is this feature important to you? How would it benefit the community?

Issues this would solve in comparison to today's practice of using many small scripts instead of few larger ones:

• Less overall memory use, since a script consumes memory by just having a state and an even listener.

• Less script time usage due to less string parsing when passing data between scripts. Right now to communicate between scripts in a linkset your primary option is to use llMessageLinked. If you need to pass lists (which you usually do), you'll have to do string parsing which is much slower than using lists directly. Especially when you wind up with many scripts in a project. Then all scripts with a link_message handler have to check each message to see if it was targeted towards them, which costs additional script time.

• Less asynchronous issues. One of the pains of LSL development is that there are no anonymous functions that can be used for callbacks, making development a pain if many scripts need to share up to date data. Not having to split scripts would remedy that.

  Potential issues this would create, and suggested fixes:

• Issue: Feature is premium only. A premium user compiles a script using 256k and sends it to a non-premium user. What happens now?

• Suggested Fix: The non-premium user can use the script as is, but won't be able to re-compile it without a premium account. If the script is moddable and they copy paste the code into a new script, it will be treated by their compile settings, potentially generating a stack overflow if it consumed too much memory. Likewise if the user's premium expires. They can still use the script but not compile it until they restore premium.

• Issue: Beginner scripters setting memory cap to max, even if they don't need it.

• Suggested Fix: Have the options in the drop down default to, and show "recommended" 64k. If changed to anything higher, add a small notice akin to "This is a high memory allocation. If you're not sure what this is, leave it at 64k (default)". Or do like you did for mesh import, having to complete a short questionnaire before utilizing the feature. There were complaints about nobody using llSetMemoryLimit, but most people don't know how that feature works or what it does. Putting a memory limit option directly in the compile window with a hover tooltip would help.

• Issue: Legacy viewers!

• Suggested Fix: If no memory limit selection is sent to the server on compile time on a mono script, it should compile with the default 64k**

• Issue: Would this work for mono only?

• Suggested Fix: Probably yeah. People today sometimes say they compile things as LSL2 to save memory. If they were able to limit mono to 16k or lower for their tiny scripts, there's no real need to compile as LSL2 other than for legacy purposes?

• Issue: With 4 times more script memory, it would be 4 times easier for abusers to flood the region's allocated memory.

• Suggested fix: Limit the feature to premium accounts. People will be less prone to abuse if there's a monetary investment in it.

• Issue: What about limiting this to experiences?

• Solution: Please no, if these improvements help reduce load on the region, it would be to everyone's benefit if projects could utilize this anywhere in the world.

• Issue: A higher memory cap would slow region crossings.

• Solution: Oz mentioned this. Currently scripters go around the memory limit by splitting their project into multiple scripts. Would a 256k script cause more region crossing delay than 4x 64k scripts? And if so, by how much?

Links

Related

• [BUG-40507] Scripting -> More memory allowances for those who are proven to not grief #12179
• [BUG-9382] llSetMemoryLimit Memory Consideration #16889
• [BUG-8761] [Experience Tools] Feature Request: Option to compile scripts larger than 64KB with Experiences. #16346
• [BUG-40705] Enable llSetMemoryLimit() to Set Sizes Above 64kb #12342

{
  'Business Unit': ['Platform'],
  'Date of First Response': '2017-08-23T15:03:47.118-0500',
  'How would you like the feature to work?': "(Oz told me it was ok to make a new JIRA post about this)\r\n\r\nAllow users to select a higher memory cap through a drop down on compile time. I suggest a 16/32/64 etc cap, with the highest option preferably not lower than 256k.\r\n\r\nI'm ok with memory caps above 64k being limited to premium users, but not to experiences.",
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Issues this would solve in comparison to today\'s practice of using many small scripts instead of few larger ones:\r\n\r\n* Less memory use, since a script consumes memory by just having a state and an even listener.\r\n* Less script time usage due to less string parsing when passing data between scripts. Right now to communicate between scripts in a linkset your primary option is to use llMessageLinked. If you need to pass lists (which you usually do), you\'ll have to do string parsing which is much slower than using lists directly. Especially when you wind up with many scripts in a project. Then all scripts with a link_message handler have to check each message to see if it was targeted towards them, which costs additional script time.\r\n* Less asynchronous issues. One of the pains of LSL development is that there are no anonymous functions that can be used for callbacks, making development a pain if many scripts need to share up to date data. Not having to split scripts would remedy that.\r\n\r\nPotential issues this would create, and suggested fixes:\r\n\r\n* Issue: Feature is premium only. A premium user compiles a script using 256k and sends it to a non-premium user. What happens now?\r\n* Suggested Fix: The non-premium user can use the script as is, but won\'t be able to re-compile it without a premium account. If the script is moddable and they copy paste the code into a new script, it will be treated by their compile settings, potentially generating a stack overflow if it consumed too much memory. Likewise if the user\'s premium expires. They can still use the script but not compile it until they restore premium.\r\n\r\n* Issue: Beginner scripters setting memory cap to max, even if they don\'t need it.\r\n* Suggested Fix: Have the options in the drop down show "recommended" on 64k. If changed to anything higher, add a small notice akin to "This is a high memory allocation. If you\'re not sure what this is, leave it at 64k (default)". Or just do like you did for mesh import with having to complete a short questionnaire.\r\n\r\n* Issue: With 4 times more script memory, it would be 4 times easier for abusers to flood the region\'s allocated memory. \r\n* Suggested fix: Limit the feature to premium accounts. People will be less prone to abuse if there\'s a monetary investment in it.\r\n\r\n* Issue: What about limiting this to experiences?\r\n* Solution: Please no, there are so many non-experience project that would see benefits from this.',
}