Script memory

Hello,

scripts are limited to 16 kB, but what does that mean?

Are the 16 kB used for both the script's runtime processes, and the code that I write? If so, then it seems that I should use short, non-descriptive function and variable names, and no comments, if I want to save on memory...but that's not good coding practice!

Does anyone have information on whether the script code counts towards the 16 kB limit?

The LSL memory space is divided into four sections: Byte-code, Stack, Free Memory, Heap. Free Memory isn't an allocated block of memory, it's just the space between Stack and Heap. The size of all four sections combined is 16384 bytes.
[...]
The Heap can become fragmented and blocks of memory in it can become unusable. There is no defragment function but there are scripting techniques that can be used to reduce fragmentation.

http://wiki.secondlife.com/wiki/LlGetFreeMemory
http://wiki.secondlife.com/wiki/LSL_Script_Memory

the mono compiler allows dynamic memory use, but for backwards compartibility and speed they made it use 1, 2, 3, or 4 x 16k blocks.

Function names and variable names do NOT appear in the byte code, nor do comments. Do yourself a favor and use nice meaningful names.

Save space by using functions to avoid repeated code. Use a variable rather than a literal string if you use the string more than once (and it's more than a couple characters long).

Most of all, use good logic and sensible algorithms. More often than not, that saves more memory than peephole optimization.

I always hear people say there are ways, but nobody will ever reveal what those ways actually are. Can you point to some reference material on that?

I could point you to lsl wikis that could try to teach you now to write more efficient but,
...most of it is very vague or very complex, some routines are more about "believing" this is better, than about tested "efficiency" for all cases.
...with the mono compiler coming to main grid likely this year, this knowledge becomes obsolete.
...there is no noticable difference, except when you manipulate long lists or many strings very often.
...coding efficient may cost more time than time being saved due to efficiency while conditions of efficiency may change even more rapidly.

http://wiki.secondlife.com/wiki/LSL_Script_Efficiency

There are always many ways achieve the same result with barely noticable differences, so why spend as much time as possible for the best way, while contidions for what actually is the best way may change faster than you can adapt?

Basic fragmentation lesson 1) Declare a value as empty before you add someting to it:
For example... 'string a="test";a=a+a;' when executing the second statement 'a' is not deallocated until after 'a+a' is calculated and the result of 'a+a' is not moved down into the memory space; meaning that the space used by 'a' originally is lost. To reduce the leak the space leaked in the above exmple there is a solution: 'string a="test";a=(a=""+a+a;'. In some scripts this is actualy what I do to help free up memory.
Same goes for lists: list b=["test"];b=(b=[])+b+b;
or just use a+=a; b+=b; , no word if that wastes memory or not on this one???

basic efficiency lesson 2: integer i=2;do{}while(--i); Is a fast, small and efficient loop, any other loop is less efficient, slower and needs more bytecode!
Design your loops as an integer countdown to 1 or 0 with {}while(--i); or {}while(i--); (i forgot which is wich) whenever possible and make sure it reaches "0" in nominal time, aka it never reaches a negative value, that would be a nearly endless loop;

I agree. I just like to know such things, there was a script i was working on recently where literally every byte counted. But having tried it in the Mono Beta, I now have over 25k free ^.^ So I guess I just want to know for the sheer joy of learning at this point. Besides, you never know, some of these techniques may carry over, and there may be one day when 64k is so completely frustrating and constricting.

Thanks for the reply and information.

I remember thinking I had all the space I could need when my first Dragon64 replaced my Dragon32, which had already replaced my 8kb 6809 trainer. When I got an IBM XT with 640K it was like owning a mainframe, It even had a 30MB hard drive.
Today I was looking at how much space I have left on my 300GB drive and decided it was time for a new one and another 2 Gig of ram whilst im at the computer store. So yes, one day 64k will be so completely frustrating, and I predict by september this year

yes, the original Computer designers predicted 64k would be much more than anyone would ever need. Boy was that a bad prediction

The most common one is using the funky syntax for appending to an array, where you clear it and add it to itself.

The problem is it's nontrivial to avoid fragmentation. The main thing is to avoid allocating a small temporary item just before allocating a larger permanent item (and then freeing the smaller item), where the size of the smaller item is bigger each time. I believe that's the case cured by the odd syntax mentioned above.

The amount of code in your script can reduce the amount of free memory to something unusable. It really isn't that hard to do. While the names of functions, variables, states, etc. don't matter because they are stripped by the compiler, the amount of logic certainly does. I've created scripts with code partitioned into many well defined functions and states that just had too little space left to function.

The lesson is that when you are building a relatively complex system, plan from the start to break the functionality up into small modular SCRIPTS, not just functions and states. Keep in mind from the very beginning where the logic may be split into tasks with link message (or other) input and output.

It's the environment we've been given. MONO may relieve it a tiny bit when it comes, but the limit is still in the same order of magnitude and it won't take long at all to butt up against the new one. So best to plan ahead whenever a project may conceivably grow to a moderate size.

That's probably a reference to the original IBM PC architecture, which had a 16 bit word and reserved 640K of address space for working memory. I doubt the Eniac inventors thought in those terms, while computers in the 60's had already exceeded 64K.