Talk:Code Sizer

From Second Life Wiki
Jump to: navigation, search

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 -

   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.
       }
   }

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)
I wouldn't say that "Even Mono experts describe Mono's memory management and garbage collection as squirrely and non-deterministic at best, so expect a few puzzling results in Mono." is exactly an "explanation of the 512-byte change" (I didn't see a 512 byte change btw). It would be nice to actually know what was going on but frankly, I am not going to lose any sleep over it. I am far more concerned about how the Script library has many bad scripts or scripts like the original of this that can't be considered up to date or accurately presented. *shrugs* I am very tired though. -- Fred Gandt (talk|contribs) 20:53, 26 April 2010 (UTC)