Difference between revisions of "User:Toy Wylie/Misc/Script Memory"

From Second Life Wiki
Jump to navigation Jump to search
(added second example with memory limit and explanation about when it's useful)
m (+cat :3)
 
Line 72: Line 72:


But this is only good for static scripts like this one. If your script uses a lot of memory for a short period of time and most of the remaining time sits idle with little to no memory usage, this approach will not work at all. And having to manually re-set the memory limit for each part of the script adds more code and more ways for it to fail.
But this is only good for static scripts like this one. If your script uses a lot of memory for a short period of time and most of the remaining time sits idle with little to no memory usage, this approach will not work at all. And having to manually re-set the memory limit for each part of the script adds more code and more ways for it to fail.
{{Resource Conservation Portal Nav|cat=memory}}

Latest revision as of 15:51, 31 March 2014

This is an example on why Script Memory Reporters are a bad thing and can't provide the information a land owner is looking for. Banning or kicking people because of the reported script memory size is not helping the case. What we really need is an accurate reporting tool that does not rely on scripts playing nice but reports the true facts regardless of how the script was made.

Some Myths and Facts

Myth: Mono scripts are much larger! They show as 64k on my reporter, while LSO scripts only need 16k

Fact: This is inaccurate. It is true that a Mono script needs more memory for the same source code size. However, an LSO script always allocates and uses the full 16k it gets, while a Mono script only uses what it needs, in 4k blocks. And since a lot of scripts are usually very small helper scripts, the memory consumption of Mono scripts is actually lower than LSO:

<lsl>// This standard door script takes up 4412 bytes in Mono // and 16384 bytes in LSO. An outside script reporting tool // would report it as 65536 bytes in Mono and 16384 in LSO.

rotation home; integer isOpen=FALSE;

open() {

   if(isOpen)
       llSetLocalRot(home);
   else
   {
       home=llGetLocalRot();
       llSetLocalRot(home*llEuler2Rot(<0.0,0.0,90.0>*DEG_TO_RAD));
   }
   isOpen=!isOpen;

}

default {

   touch_start(integer total_number)
   {
       llOwnerSay((string) llGetUsedMemory());
       open();
   }

} </lsl>

Using the new llSetMemoryLimit function we can make the situation a little bit better:

<lsl>// This modified standard door script takes up 4924 bytes in Mono // and 16384 bytes in LSO. An outside script reporting tool // would report it as 5000 bytes in Mono and 16384 in LSO.

rotation home; integer isOpen=FALSE;

open() {

   if(isOpen)
       llSetLocalRot(home);
   else
   {
       home=llGetLocalRot();
       llSetLocalRot(home*llEuler2Rot(<0.0,0.0,90.0>*DEG_TO_RAD));
   }
   isOpen=!isOpen;

}

default {

   state_entry()
   {
       llSetMemoryLimit(5000);
   }
   touch_start(integer total_number)
   {
       llOwnerSay((string) llGetUsedMemory());
       open();
   }

} </lsl>

But this is only good for static scripts like this one. If your script uses a lot of memory for a short period of time and most of the remaining time sits idle with little to no memory usage, this approach will not work at all. And having to manually re-set the memory limit for each part of the script adds more code and more ways for it to fail.