I’m going to talk here about a relatively new scripting function, llSetMemoryLimit, this may not work the way one thinks it does, but it basically sets the upper memory limit your script can use. I’m far from being a scripting expert but this looks like a function that people should get used to using where they can, even if it might not actually save memory for a sim the way we may think it should, I’m not sure how the server handles the space.
Anyway, when you create a new script, if Mono is ticked, it has an upper memory limit of 64kb, if you don’t compile the script as Mono, it compiles as LSO, and that has an upper memory limit of 16kb, with LSO it’s a hard rule, all LSO scripts have an upper limit of 16kb, llSetMemoryLimit won’t work with LSO, with Mono however you can set a lower limit. In this post I’ll show how this works with a very basic script, a notecard giver.
I’ll start by visiting LSL Wiki and going to the llGiveInventory section. LSL Wiki isn’t as up to date as the LSL portal but I often find the discussions and examples on LSL Wiki more helpful. So all I want is a notecard giver, I rez a prim, go to the contents tab, click new script, get the default hello world script, delete everything and replace it with this (with apologies for the horrid coding style):
default
{
state_entry()
{
}
touch_start(integer total_number)
{
llGiveInventory(llDetectedKey(0),llGetInventoryName(INVENTORY_NOTECARD, 0));
}
Then I make sure there’s a notecard in the contents of the prim and when I touch it, I’ll get a Notecard. However this is a Mono script so it defaults to an upper memory limit of 64kb:
So let’s look at how we can reduce that using llSetMemoryLimit()
Now the first thing to note here is that I wouldn’t put a for sale script out there using this method, but it gives you an idea of how things work. There are a few ways of getting an idea of how much memory a script uses but what I’m going to do here is use llScriptProfiler and base my test on the example there. Note the caveats there, having the profiler on adds to overheads. I’m going to run the profiler, find out how much memory the script uses then set my memory limit to that figure, I wouldn’t advise people do this for production scripts, I’d add some spare capacity, but this gives you an idea on what you can do. My new script will look like this:
integer limit = 64000;
{
default
{
state_entry()
{
llSetMemoryLimit(limit);
}
touch_start(integer total_number)
{
llScriptProfiler(PROFILE_SCRIPT_MEMORY);
llGiveInventory(llDetectedKey(0),llGetInventoryName(INVENTORY_NOTECARD, 0));
llScriptProfiler(PROFILE_NONE);
llOwnerSay(“This script used at most ” + (string)llGetSPMaxMemory() + ” bytes of memory during Touching.”);
limit = llGetSPMaxMemory();
llSetMemoryLimit(limit);
}
}
Now when I touch the script, I’ll see this:
Then when I go to about land and look at script info under the general tab, I’ll see that it is indeed only reporting my script as 4kb:
Then I go a bit mad and rez another three of these objects, touch them a couple of times to make sure they don’t crash and then find that about land/script info now shows this:
Now is the point where I get confused, I’m not sure what this actually does in terms of saving memory allocations or whether it does indeed do that. Yes I can reduce the way my script gets reported, but my notecard script would never use more than the amount llScriptProfiler reported, indeed it uses more than it needs to because I’m running the profiler. Someone like Kelly Linden would be needed to explain how this actually works, whether it saves any memory and whether it’s actually useful, I see it as a good practice tool.
However, depending upon your script, you’d need to be careful with this, for simple scripts it’s fine but for scripts where users may be adding variables or data to lists, you’re going to want to leave room for your script to grow and just how much memory you need for that, only time will tell.
So as it stands I’d treat this with caution, but it’s worth noting and worth using when you can just to get into the habit of using it and knowing yourself that your scripts aren’t eating up huge amounts of memory.
It seems more and more places are using those “Everyone ridicule this user because they are using the most memory and therefore causing the most lag” monitoring signs. Although the intention of reducing server lag is good, the problem is most people just don’t understand how script/lag works.
Those monitors report what the maximum data “could” be. Just as your article points out, Mono has an upper limit of 64kb whereas the great majority of Mono scripts are going to be using between 4-8kb. The monitors could be reporting 16 times the amount of data than is actually being used. This is where llSetMemoryLimit comes in. It reports a more accurate number, or at least a closer number to what is actually being used.
Another problem with those monitors (not related to the article), is that they equate script memory usage to lag. What baffles my mind is how anyone smart enough to write one of those monitors can think they are directly related (or maybe they are smart enough to realize how ignorant their patrons are?). If you really want to reduce sim lag, remove the monitoring devices that change prim properties every fraction of a second and kick all the users with the worst latency and packet loss.
Summer, the problem isn’t with the tools, it’s with the people. Some people just want someone to ridicule. We can’t discriminate in SL on most of the usual grounds; no one’s overweight, or unattractive, or of any particular race except by choice. The only people to discriminate against are the furries, and at least in my experience they seldom leave their ghetto because of it. Now we can look down on people who run more scripts than we do, even if in truth they’re not a problem for anyone.
Yeah, my faith in humanity is lacking.
My problem is more with the way those things are marketed. People who just don’t know or understand how SL works think that more script memory = more lag. When the reality is script memory has nothing to do with lag other than when the agent enters the sim and its receiving a memory dump for the previous location (often times causing everyone in the sim to freeze). Witch hunts abound in SL and this is just one more thing to drag out the pitchforks over.
To make matters worse, unless the script author has used this function to cap the memory those products only report the full amount it could use, making it seem far worse than it is in reality. A person could be wearing a 10 small scripts reported at 640kb (really only using 40kb) and another could be wearing a very complex hud that is scanning non stop and reported as only 1 script at 64kb (really using 60kb). Yet the low memory user is made to look like the bad guy when the real crime is the guy not even on the sign wearing no scripts and suffering from major packet loss forcing the sim to hammer on his i/o causing everyone to rubberband walk.
Now in order to combat ignorance, script authors have to put in caps? Why? If the memory isn’t used, it isn’t used. Period. “Unused memory is wasted memory” and has nothing to do with lag or cpu cycles. I just don’t see any programmers rushing to do this until Linden Lab puts in land caps for memory usage and even then it’s usage will be arbitrary.
Indeed, sometimes making more information available isn’t beneficial because people don’t understand what the information means. I can recall even telling a Linden that Avatar Rendering Cost was a client side score.
This was one of the issues that needed to be addressed when LL were talking of imposing script limits, Mono scripts would look more resource heavy because they reported as using 64kb each.
I’m still confused as to whether memory gets reserved and is unavailable to other scripts even when you set a limit or whether it only uses what it needs and the rest is spare.
We had this misnformation malarkey with Avatar Rendering Costs, it’s not helpful for people to put too much faith in these meters, if we all went bald we’d all seem to be lower lag, whether we are is another issue.
Still going strong, I see, Ciaran 🙂 SL is truly like a whole other (alien) world to me now that I’ve been away for more than a year. Glad you’re still having fun, exploring and learning new stuff!
You should come visit me!
I might at that! But you still live in a ridiculous time zone!