{
  'Business Unit': ['Platform'],
  'How would you like the feature to work?': 'When llSetMemoryLimit was first implemented, Babbage Linden (who is no longer with us) had three projects he was heading: efficient scripts, small scripts, and big scripts. Efficient scripts and small scripts were, for the most part, implemented. Now, bear with me. Hear me out. Yes, the next words I will say are "big scripts" but this feature request is more moderate.\r\n\r\nBig Scripts, and using llSetMemoryLimit to request memory amounts larger than 64kb was never implemented. I\'m not sure if that\'s because Babbage left LL before it could be completed or for some other reason, but I think it is ultimately vital to have it reviewed in some form. So here is my proposal:\r\n\r\n* Allow llSetMemoryLimit to request **up to** 128kb or 256kb of memory (whichever is more feasible)\r\n* Throttle script performance in cases where less than 50% of the memory requested is being used',
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Babbage had originally intended to allow scripts to request megabytes of memory. This request is more conservative, however, larger scripts are, and have been, a pressing need for a long time. The current 64kb script memory limit isn\'t just inconvenient, but it\'s also unhealthy for the servers.\r\n\r\nI am not an inexperienced scripter. I\'m familiar with memory-saving techniques, being conservative with script time, and trying to manage my data in a fashion that isn\'t wasteful, from using bitwise operations to store a ton of data to how to use math operations and more. I try to improve all the time.\r\n\r\nIt\'s just a simple fact, however, that some interfaces (especially with the advent of mesh) are too complex to fit in 64kb and still have memory to run, especially user interfaces. For many complex end-user applications, a scripter is **forced** to split one script into two or more, and must devote a sizeable portion of the freed memory in both scripts **just** to communicating between the scripts and avoiding race conditions to carry out the same operations. This also increases the server\'s script time and event queue. Most of the time, with normal memory-saving techniques, this could have been totally avoided if just one script had been given even  a little more generous memory limit, and ultimately cost less memory overall because you don\'t have to allot script memory for both scripts or their communication.\r\n\r\nGiven the chance, many script writers would jump at being able to shrink their multi-script items into one. I think most have given up hoping (almost myself included, except I\'m writing this JIRA). Script optimization can only carry you so far, and people who are less familiar with scripting will often resort to even less efficient means of getting done what they\'re trying to do.\r\n\r\nSo, in the "big picture," the 64kb memory limit may be a generous "default" memory setting, but it\'s important that higher script memory limits be allowed. As it stands, many scripters grind their teeth trying to crunch numbers that can\'t be crunched when working on more complex projects, and overall having that insurmountable limit is more damaging to the sim environment than it is beneficial due to the methods scripters are forced to resort to.\r\n\r\nThank you for reading.',
}