Resize Scripts: A Brief Survey

[Kwakkelde Kwak]

I don't know what you're trying to show with these two scripts. All I can conclude from those two, is that the limit is too small and therefor ignored when the script is compiled. No script can use just 3000 bytes, a simple state_entry with a single function uses more than that.

The stack-heap occurs when the memory limit IS set and the memory gets higher than that limit.

It is not likely to happen in a script like yours without any variables. In the second script you can see the difference between the first and second event, it's a small difference. Set the limit to 4916 instead of 3000 and you'll see the script will compile, but give a stack-heap collision right away.

[Erik Verity]

---

Madeline Blackbart wrote:

I will admit I am a horrible person with this. I were upwards of 200 scripts or more at a time. To be fair they general seem to be well written scripts and come under the 2mb of run time or so... I think one needs to consider more then just number of scripts but quality. As one script that's poorly written can be as laggy as 10 or more.

---

And this brings the subject back in line with the OP.

Number of scripts can very much be a problem also, even when well written. Every script has to be accounted for by the simulator, and takes a slice of time, even if it is empty. When you get high numbers of scripts, even with low memory usage, they start to make a real difference in slowing down all of the scripts on a region. The newer scripting functions that allow a single script to affect other prims in a linkset were specifically created to cut down on the number of scripts; not just their memory usage.

Deleting resize scripts really is not very important at all if it only addresses a single, small, well written script. Even with 40 avatars in a region, if each deleted a single resize script they had for an item they were wearing, you probably would not notice any difference at all from a case where they each kept that single script included in their attachment. Deleting them when each link in the set has its own script absolutely makes a huge difference. I have a pair of shoes I consider useless because they are no mod and I cannot delete their resizers - there is a script in each of the prims and I believe they are over 90 prims in each shoe. I bought them when I was new and knew no better.

I don't see anything wrong with having a lot of scripts or otherwise being script-heavy sometimes - if we can never go all out once in a while for the purpose of having fun with some nice abilities, there would have been no reason for most users to have ever signed up in the first place. But a lot of avatars in a busy sim can't possibly do it at the same time and expect the sim to keep running.

[Max Nova]

I do if I can, that is to say after I take a copy of the original and if the product is "MOD". I try only to buy products that are copy, mod for obvious reasons. That being said some of the clothing I have has tons of scripts and some sims will not allow you in with a high script count so, it is best to remove them if there are a lot. If you have a decent computer that complies with SL requirements you should never experience "lag" or freezing (unless there is a server problem) however; it seems that at least 50% of the people on SL have non-compliant computers and they will blame you for being over scripted which is in fact crap. Here is a link to the wiki about scripts and lag if you have interest: http://wiki.secondlife.com/wiki/Lag

[PeterCanessa Oh]

---

WuShin wrote:

... If you have a decent computer that complies with SL requirements you should never experience "lag" or freezing (unless there is a server problem) however; it seems that at least 50% of the people on SL have non-compliant computers and they will blame you for being over scripted which is in fact crap...

---

While it is true that scripts have the lowest processing priority and that, therefore, scripts only lag other scripts the can be significant impact on a sim when a lot of scripts have to be rezzed at once (eg; when someone wearing tons enters the sim).  It is also important to remember that the 'other' scripts you are lagging are probably ones the sim-owner considers more important than the ones in your clothes ^^  Similarly, other people in the sim may be a bit miffed if one person is hogging what script processing time is available.  Of course that still leaves 'too many scripts' as an almost entirely subjective number,

[Paul Hexem]

At the sim where I'm staff, I regularly see people wearing 500 to 900 scripts. Usually resizers.

[Kwakkelde Kwak]

---

WuShin wrote:

If you have a decent computer that complies with SL requirements you should never experience "lag" or freezing (unless there is a server problem)

---

Scripts run on the server, so causing server problems is exactly what they do, well, if there are too many anyway. You can have the fastest computer on earth, but that has no influence at all on server performance.

[PeterCanessa Oh]

---

Gadget Portal wrote:

At the sim where I'm staff, I regularly see people wearing 500 to 900 scripts. Usually resizers.

---

Ouch, that's bad.  I wouldn't expect to see that sort of thing these days at all.

Worst I heard of though was 36,000 scripts!  A newbie who only knew how to 'wear' a folder-full of items, not single things.  So she wore her entire colour-collection of a particular hairstyle, each one of which had a per-prim resizer script.  ^^

[steph Arnott]

I ran extensive tests and you are incorrect, there is no stack heap error unless it over 64Kb and the memory set is ignored and 64Kb is reinstated.

[Kwakkelde Kwak]

Apparantly you didn't listen to what I said about your scripts.

Apparantly you didn't even bother to use the script I posted.

Apparantly you didn't set the memory limit high enough on compile.

You can test all you want, but if you run the wrong tests you will get wrong results. Show a script that ignores the script limit AFTER compile, not DURING compile. In other words, make a script that has a limit lower than 64k (not 3k, that is a stupid number that can never be a limit), then keep adding data to the script until it runs out of memory. Just make a simple script with a memory limit of let's say 4-5k, then keep adding to a list on touch so the memory use increases a bit every time. Oh wait, that's the script I posted to show you how it works.

[Kwakkelde Kwak]

string Something;

 

default

{

    state_entry()

    {

        llSetMemoryLimit(4450);

        Something = "A";

        llSetTimerEvent(1);

    }

 

    timer()

    {

        llSay(0, (string)llGetFreeMemory() + " bytes out of " + (string)llGetMemoryLimit() + " free, " + (string)llGetUsedMemory() + " bytes used.");

        Something = Something+"A";

    }

}

 Another one, maybe this will make it clearer. Just put that script in a prim and watch what happens below.

[08:18] Object: 38 bytes out of 4450 free, 4412 bytes used.

[08:18] Object: 36 bytes out of 4450 free, 4414 bytes used.

[08:18] Object: 34 bytes out of 4450 free, 4416 bytes used.

[08:18] Object: 32 bytes out of 4450 free, 4418 bytes used.

[08:18] Object: 30 bytes out of 4450 free, 4420 bytes used.

[08:18] Object: 28 bytes out of 4450 free, 4422 bytes used.

[08:18] Object: 26 bytes out of 4450 free, 4424 bytes used.

[08:18] Object: 24 bytes out of 4450 free, 4426 bytes used.

[08:18] Object: 22 bytes out of 4450 free, 4428 bytes used.

[08:18] Object: 20 bytes out of 4450 free, 4430 bytes used.

[08:18] Object: 18 bytes out of 4450 free, 4432 bytes used.

[08:18] Object: 16 bytes out of 4450 free, 4434 bytes used.

[08:18] Object: 14 bytes out of 4450 free, 4436 bytes used.

[08:18] Object: 12 bytes out of 4450 free, 4438 bytes used.

[08:18] Object: 10 bytes out of 4450 free, 4440 bytes used.

[08:18] Object: 8 bytes out of 4450 free, 4442 bytes used.

[08:18] Object: 6 bytes out of 4450 free, 4444 bytes used.

[08:18] Object: 4 bytes out of 4450 free, 4446 bytes used.

[08:18] Object: 2 bytes out of 4450 free, 4448 bytes used.

[08:18] Object: 0 bytes out of 4450 free, 4450 bytes used.

And then, surprise, a stack heap collision.

 

[steph Arnott]

I ran a loop test, if the loop is running it will stack heap error, the memory limit is obeyed in that part. But i see no use for a script that's adding to memory to run an endless loop till it hits any limit, if a loop was running for a reason then the limit would be set to accommodate.

ADDED: Basically if the script never ends it will error.

[Kwakkelde Kwak]

huh

[steph Arnott]

Your code only proves that if one wants to break somtehing you can,

[Dillon Levenque]

Hulk smash.

 

 

 

[Kwakkelde Kwak]

No, my code proves that if the memory limit is active, you will get a stack heap error when that limit is exceeded.

Therefor the script is not useless, it's just not a script you'd use otherwise. It's pretty clear.

I can think of countless scripts that in a technical way do exactly what my little script does. For example, creating a list with people that visited your sim in the last day. In scripts like that you will have to make either the memory limit variable, or if the limit is almost reached, the script should remove some names from the list before adding new ones, or move parts of the list to a new script with more memory available, or a combination of these.

OR you just forget about this entire memory limit since the only use for it is giving an estimation of memory use of mono scripts. In other words, only the estate tools and some lag meters will pick up on it. These tools do not pick up actual memory use and are therefor pretty useless themselves. Like I posted before, the function is a left over from the days that LL wanted to put a cap on memory use per avatar (and per region if I'm not mistaken).

I do have to correct myself on a small but important thing, the memory limit isn't set when compiling the script. It's set when the llSetMemoryLimit is executed of course. That might have caused your assumption that (sometimes) the limit is ignored. So if a script gathers some (variable) data before the limit is set, it's possible that in some cases the limit is actually set and sometimes not. That still doesn't mean that if the memory use goes over the limit, the limit is ignored. It means that if the memory use is higher than the limit on excecution of the function, the limit is simply not set. I would say that's some pretty poor coding, the limit needs to be set in such a way that it's never lower than the memory in use, very easy to check and very easy to set.

EDIT One thing that crossed my mind, this whole argument started when someone said their memory use was this and that for this and that amount of scripts. I don't know how that was measured, but if those scripts were all duplicates of a mono script, that's very easy to accomplish, since duplicate mono scripts share their memory. In other words, in theory you could have hundreds of scripts with a total memory use of just a couple of thousand bytes.