Increasing the memory limit for scripts

If you've read my other thread then you know I'm struggling through with a script that has a few stack-heap collision issues.
Well, the issue here isn't actually the intensity of my script, it actually does very little when it's active, even in use it barely does any work!
But there is that much code (a lot of it for initialising the object to begin with; ie reading settings) that I have about 1kb of memory left for the variables, which as you can imagine isn't leaving me much room to manoeuvre!

So anyway, I'm thinking to myself, I wish I had a bit more memory to work with...

...and that's simply it! With the 1.7 update, scripts no longer lag the sim, because it's the scripts which slow down and not the sim's frame-rates. So having a restrictive memory limit no longer forces people to code cleanly, the new timing mechanics will, because a poorly coded script will now run very slowly.

What I'm proposing is a small increase in script memory allocation, something like 24k overall, 32k would be ideal for storing large data-sets (as they do little work, just store).

The thing about my script is that it isn't easily distanced, there are no more parts that I can take out and place into a seperate script, the list used by my script is already positioned like this! All the functions in the script work together quite a lot, and the act of taking some out and placing them into a seperate script would end up with the same amount of code being required to deal with the new link messages being passed about.
Admittedly the 16k limit has forced my code to get only more efficient, but I'm at the end now, the thing's so damned clean you could eat your dinner off of it!

I haven't read your previous posts, but try splitting your script into two or more different scripts within the same prim. Then, have each script handle a certain portion of your "settings" or whatever you're filling the memory with.

If you're reading alphabet data, have a script do A-M and the other N-Z.... if you're programming data to be checked later, have one script check the first half, if it passes, send a message to script#2 which will complete the check of the second half of date.

I've managed to break it up a bit more, freeing up 500 bytes or so which is fine for now. But there is literally no more that can be taken out, all that's left is necessary to the overall functioning. If you saw how huge it is then consider how little it actually does once it's started then you'd understand the frustration, but all of it is needed for it to function as I require

What with the hardware upgrades going on at the moment, I'm kinda hoping it might get slipped into 1.8

I didn't think this topic had posted actually, my browser decided to take the opportunity to close itself when I clicked Submit, I thought it had been lost!
Haven't posted/searched for the feature request yet, as I can't get in due to the upgrade =(

From my understand from similar threads/discussions in the past, LL kinda coded LSL in a way that it would be extremely difficult to increase the memory limit and pretty much have stated that it would not increase while the current implementation of LSL is being used. They did state, however, that they are working on implementing Mono as a replacement for their current VM and that the memory restrictions would be removed when it got implemented (not to mention supposively a dramatic increase in script speed).

I'm actualy not so sure about this, i've looked at the bytecode format and am pretty sure if you were motivated you could upload a script with greater memory consumption.

With mono scripts don't have there memory allocation being static, when you need more memory it declares it. That said they still are putting a 16k limit on memory. If you are interested you should read about it on Babbages Blog.

I just had to split my script into two.

I wish LL would realize that doing so creates MORE server lag than letting us have more space.

All I did was complicate my code, increase it's size and now have two scripts running instead of one.

16k simply isn't enough for some of the more complicated things we're doing.