![]() ![]() When you touch it, it will offer you a dialog where you can play any of the animations, or stop the one currently playing. Rez a prim, drop this script in it, and a bunch of animations, then take and wear it as a HUD. Sometimes, you just need something simple to pick an animation to play. If every script creator did this, we’d be living much less laggy second lives! The init_profile () call just sets the memory limit when PROFILE is undefined (and the show_profile () call is replaced by a blank line of code). Once you’ve figured out a good number for MEMLIMIT, don’t forget to turn off debugging and profiling by changing the #define DEBUG and #define PROFILE to #undef DEBUG and #undef PROFILE, and leave the init_profile () and show_profile () calls in place. Doing this simple exercise saved over 56K! That may not sound like a lot, but don’t forget there can be thousands of scripts running in a region, so it adds up. I will leave a little buffer between the size reported and the limit, just in case □ So in my example, I left MEMLIMIT at 8000. Increase the size of MEMLIMIT until this message goes away. If you see Barrier: MEMLIMIT = 8000 too small This tells us that at the end of the timer event, the most memory the script has ever used is 7598 bytes, so our starting figure of 8000 was close. When you save this, and collide with it (if you’re trying this, don’t forget to replace my UUID with yours!), you’ll see something similar to the following… Barrier: Memory profile init: 0īarrier: Memory profile show (timer): 7598 So the logical place to put the show_profile () call is at the end of the timer. It can be tricky to figure out where to put this call, but in this case, it’s easy, as the script flow first sets everything up and then waits for a collision by me, followed by the timer firing. The show_profile () call displays the current maximum amount of memory the script has used. The init_profile () call sets the script’s memory limit based on the MEMLIMIT definition, and starts memory profiling if PROFILE is defined (and, just a warning here, memory profiling can drastically slow down your script so make sure you turn it off when done!) Now notice the calls to init_profile () and show_profile (). The code at the top includes my standard debugging code, and the #define MEMLIMIT 8000ĭefines an initial memory limit of 8000 bytes, tells profile.lsl to enable profiling, and includes the profiling code. It takes no external input, all the memory it will use is its code, it doesn’t even use any variables! So this is a perfect candidate for limiting script memory allocation. It lets me walk through it by turning the barrier phantom when I collide with it, but for everyone else, it does nothing. This is a simple script that goes in an invisible barrier. LlSetLinkPrimitiveParamsFast (LINK_THIS, ) #include "profile.lsl" // See the source of profile.lsl #include "debug.lsl" // See the source of debug.lsl You can access the included files by following the link in the comments next to them. Let me show you an example of how I use it. To make things easy, I created an include file for my scripts. And, as you may have guessed, this post was prompted by someone triggering the swapping problem on my home sim, which made me see if I could drop the memory that my scripts allocate. So, if you have something that doesn’t allocate memory out of your control, how do you know what upper limit to set with your call to llSetMemoryLimit ()? There’s a set of memory profiling calls that will tell you. It depends on how many textures the owner loads into the frame’s contents, and not how the script creator codes the script. Typically to do this, the script will load the names of the textures into a list, and therefore the amount of memory used by the list is out of the control of the script creator. ![]() The owner can drag textures into the frame and display them. So, what as script creators can we do? If you have a script that takes no external input, you can limit the amount of memory your script will be allocated with a llSetMemoryLimit () function call.įirstly, what do I mean by “takes no external input”? An example of something that takes external input is something like a picture frame that displays the owner’s selection of textures. Swapping is a Bad Thing™ and will drastically slow down the sim, which you’ll see as lag. With thousands of scripts in a region, this can easily consume all the memory allocated to the region, and cause the region to start swapping memory out to disk (this all happens at the Linden Lab server running the region). This is true even if the script uses only a few kilobytes of memory. In Mono, which is the modern script engine, each script gets 64K of memory allocated by default. Thinking about script memory in LSL is very important. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |