Jump to content

Script memory conservation...


Life Camino
 Share

You are about to reply to a thread that has been inactive for 3522 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I have some rather large scripts that I would like to go through and streamline to make them more memory efficient.  And, I was wondering what general techniques I might employ to save script memory?

For example, I know that global variables take up more memory than local variables.  So, I try to use local variables when I can.

So, what other simple standard scripting techniques might I use to similar effect?

 

Thanks, in advance for your suggestions!

Link to comment
Share on other sites

TIP 1)

One key tip that seperates good scripters from beginners........is to use indexed lists instead of individual strings and integers wherever possible.

It's a lot more efficient both for storage memory and speed of processing. You just have to be careful because a list can grow too big and cause a stack overflow error.

TIP 2) 

It's better to put multiple conditions on an IF statement than to nest layers of IF statements inside each other. Often I will write out a script and once it is working properly I will reduce the layers of IF statements, moving the conditions into earlier IF statements.

TIP 3)

If your script is still too large then split it into multiple smaller scripts and use link messages to ferry data between scripts.

http://wiki.secondlife.com/wiki/LlMessageLinked

One secret that expert scripters rarely tell others about is......... that seperate scripts have seperate event queues and so it's a bit like having multiple processors.

If you just have one over-worked script then old actions are likely to even be dropped off the end of the queue before being completed. There is a limit of 64 events that can be held in the event queue of each script:

http://lslwiki.net/lslwiki/wakka.php?wakka=events

TIP 4)

Good scripters always think altruistically about how their script affects the player lag experience. They weigh up the additional features of their script against the lag it creates. Believe it or not customers prefer products that have this balanced approach, rather than all the bells and whistles.

One other thing about script memory that most people don't realise is that scripts ALWAYS use 64k of memory.......unless you manually specify for them to use less memory. Limiting the memory where not necessary is a great way to reduce sim lag. 

http://wiki.secondlife.com/wiki/LlSetMemoryLimit

 

A few tips from an experienced scripter. Hope that's helpful. :matte-motes-nerdy:

 

Link to comment
Share on other sites

There are several problems here, but I'll stick to my personal bugaboo:


One other thing about script memory that most people don't realise is that scripts ALWAYS use 64k of memory.......unless you manually specify for them to use less memory. Limiting the memory where not necessary is a great way to reduce sim lag. 

 

In fact, Mono scripts never use more memory than they need, nor do they "allocate" the quota that is reported to external measurements. llSetMemoryLimit merely adjusts that quota from the 64KB default, which of course causes the script to crash if it tries to allocate beyond the quota. Hence, it only reduces memory usage or lag to the extent that it prematurely crashes some scripts that contain it.

(They're rarely relevant anymore, but non-Mono, aka "LS0" scripts, always use 16KB, no matter what. Within that 16K, they're quite a bit more memory-efficient than Mono scripts, but that comes at a dramatic performance penalty for anything compute-intensive.)

Here's a completely unrelated suggestion: Inline single-use user-defined constants. You know, the constant values with ALL_CAPS variable names we all inherited from programming in languages that preprocess source before it goes to the compiler. In LSL, there's no (native) preprocessor, so those are all global variables and use memory accordingly. I generally leave some ALL_CAPS constants in comments at the top of the file, as tags to find the corresponding values similarly commented in the program itself. (This tip obviously doesn't apply to source that's only shown in an external editor and passed through a preprocessor on upload to SL.)

Also, here are a couple of sources in the wiki that may be of interest:

http://wiki.secondlife.com/wiki/User:Becky_Pippen/Script_Memory_Limits (from back when there was a plan to limit total memory use on land and in attachments).

http://wiki.secondlife.com/wiki/LSL_Script_Memory (From personal experience, I can vouch that it's very difficult to get consistent numbers for these measurements, but they give some idea of relative memory costs.)

Link to comment
Share on other sites

I have to disagree with lists being memory efficient - they aren't. Single valued variables are always more memory efficient, but more of a pain to work with (ie. a lists are easier to work with). JSON is cool, and 'may' save you some memory depending - you'll have to test. If you don't use that much data, just use lists for the easy of use.

The fastest / most efficient code is that which doesn't exist. I tend to write like an old C++ programmer writing symmetric functions for every little thing first. But once everything is working I go back through and remove all the junk. So can you consolidate some functions into one function?

In your final stage of optimization, remove all comments. Also replace triple spaces with a tab. Basically every extra char in your script uses a bit of memory.

 

 

 

Link to comment
Share on other sites

Although what they say is technically true (according to the wiki), in the practice of writing actual scripts, it is completely the opposite.

Remember that you will have to seperately reference every single individual variable, each time you want to use. Creating messy noob code that takes up 30 pages. That will more than override any technical memory savings you make through storage efficiency.

The LSL functions that handle lists are far more efficient than those that you'll be able to write out using plain LSL. They are written in a far more efficient language than LSL.

Use individual variables for temporary variable storage and global settings only. Use lists for data and any grunt work.

As for limiting script memory. If your scripts use 64k, for even a second, then that memory will be permenetely wasted because it will be buffered in there forever. The guy suggests you monitor your memory usage which is all very well and good, but he can't guarantee your script will never max out memory.

Limiting memory is best practice because then you can ensure your scripts can never use excessive resources. The only way to do that is to limit it and test it heavily and under all conditions to see if it stack overflows. 

The reason scripts are crashing due to the limit memory function, is because they weren't properly tested. In which case they shouldn't have been released in the first place. There's no excuse for wasting sim resources unecessarily.

Set strict limits on yourself and become a better scripter for it :matte-motes-sunglasses-1:

Link to comment
Share on other sites


Aztral Aeon wrote:

In your final stage of optimization, remove all comments. Also replace triple spaces with a tab. Basically every extra char in your script uses a bit of memory.

The script is compiled before running so none of this count against available script memory

:smileysurprised::):smileyvery-happy:

Link to comment
Share on other sites

  • 2 weeks later...

There are many ways to waste script memory and many ways to save script memory.  It all comes down to good programming habits.  Without seeing the script code you're talking about, I can't give you tips specific to your script.  Good habits come with time, experience and knowledge about the language you're working with.  There are important factors involved which vary from script to script, so it's difficult to narrow down where your problem areas are.

Some general tips:

  • Use local variables when possible, keeping globals to a minimum.
  • Only create functions when they're absolutely necessary (repeating code, for instance).
  • Even though llGetFreeMemory results can vary, it's still useful to approximate memory usage and test different ways of doing the same thing to maximize memory in your scripts.
  • When using lists, storing variables like keys, vectors, integers and floats as their actual data type (and not string) tends to save on script memory.  Further reducing some data types (keys, for instance) to smaller values can also save on script memory.
  • Always think efficiency first.  Take a minimalist approach in your scripts.
  • Strive to have your scripts idle, waiting for events.  Remove unnecessary listens.  Stop unnecessary timers.
  • Keep text usage (chat message text, for instance) to a minimum.  Text is one of the biggest script memory hogs.
  • Only split scripts into multiples when absolutely necessary.
  • Once you've written a script, place it in inventory, then use that script to load your objects with so that you're taking advantage of bytecode sharing and use less memory.
  • Use "Link" functions (llSetLinkPrimitiveParams, for instance) in place of using more than one script in your object's prims.
  • Consider how your scripts (and products) will impact others and plan accordingly.
  • If your script becomes bloated and you know it (typically, you do), try to reconceptualize your script design and come up with a simpler way to do something.  It might mean eliminating some features in your script, but may give a huge savings.  Choosing a lesser method of user input, for instance, can save on the code needed to do the job, thus saving on script memory.  HUD's are great for offloading input from script code to meaningful buttons, simplifying the script.
  • When it's not necessary to use text, use values to represent settings instead.
  • Learn how to use bitwise integers for script functionality.

Those are just a few.

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3522 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...