Talk:Code Sizer

MONO v LSO

I noticed this script was written for use with LSO (no mention of that fact though (unless I am missing it)) so I set about writing a version to handle both LSO and MONO. Yet again I find myself pulling faces at the screen whilst trying to make sense of MONO's free memory. I came up with this - <lsl>GetBytes(integer type) {

   integer this; // How many bytes are used (minimum) to compile and run.
   if(type == 64) this = 3844; // This amount is hard to reduce in mono
   else this = 354; // Slight changes have big effects in LSO
   llOwnerSay((string)((1024 * type) - (llGetFreeMemory() + this)));

}

default {

   state_entry()
   {
       GetBytes(16); // 1 simple call per test.
       // Although (in mono) it is very hard to tell exactly how many bytes are used by each call of GetBytes()
       // One thing is for certain...Mono is odd.
       
       // An example of code you might test -
       
       llOwnerSay(llDumpList2String(["is", "how", "much", "does", "this", "code", "take", "up", "in", "bytes?"], " "));
       
       // The llOwnerSay() above takes 512 bytes in mono and 122 in LSO
       
       // When a script is first compiled in mono there is a larger byte count used than after all subsequent resets.
       // On the first run the state_entry llOwnerSay() code takes 572 bytes. After reset 512.
       // LSO does not have this initial discrepancy.
   }

}</lsl> I am sure someone else can do better. What interests me is how we should accurately measure memory use when llGetFreeMemory returns some very odd results (if you play around with enough variants for long enough). I wonder if someone wise might share? -- Fred Gandt ^{(talk|contribs)} 23:57, 25 April 2010 (UTC)

There are a few more clues and links about Mono's memory management, including a possible explanation of the 512-byte change you saw, at this page. Also, this page shows examples of the Mono instructions that the compiler generates for an LSL function call. -- Becky Pippen 18:31, 26 April 2010 (UTC)