User:Omei Qunhua

Mono Code Size Measurements

Results from my own tests in December 2012

1) Accessing a local integer variable

  Results ordered by size

Instruction      ByteCode size
(x);                  2
(~x);                 3
x+x                   4
x=~x;                 5
x=-x;                 5
++x;                  6 
x=x+x;                6     
x=-~x;                6    equates to ++x
x=~-x;                6    equates to --x
x=x^x;                6    equates to x=0
x = !x;               7
if (~x);              7    if (x != -1)
x++;                  8
x=0;                  8
x=9;                  8
x=-~-~x;              8     equates to x+=2
x=-9;                 9     Oh !!   Does it load a +9 then negate it?
x+=1;                 10
x-=x;                 10
x=x=x;                10
x=x*2;                10
x*=2;                 10
if(!~x)               10   if (x == -1)
x *= -1;              11
x<<1;                 12
if(x<0);              13
if(x==-1);            14
x=x<<1;               14

2) Accessing a local integer variable

  Results grouped by functionality

Instruction          Size     Assumed operations
negate x:-
x=-x;                 5     (load x, negate, store)
x*=-1;                11

zeroise x:-
x=0;                  8
x=x-x;               10
x-=x;                10
x=x^x;                6     (load x, xor with x, store)

double x:-
x=x*2;                10
x=x<<1;               14
x=x+x;                6     (load x, add x, store)
x+=x;                 6

increment x by 1
++x;                  6
x++;                  8     (because it has to preserve what it knows about x from before the increment)
x=-~x;                6     (equates to ++x, not x++, so no size advantage)
x+=1;                 10

increment x by 2
x=-~-~x;              8   equates to x+=2
x+=2;                10

List storage Requirements in Mono

These figures differ from those given in http://wiki.secondlife.com/wiki/LSL_Script_Memory

Maybe Mono has been tightened up a bit.

Integer                   16 bytes each
Float                     16 bytes each
String                    18 each plus 2 bytes per character
Key (valid keys)
    (stored as keys)     102 bytes (!!) per key
Key (valid keys)
    (stored as strings)   90 bytes per key
(key) ""                  30 bytes
Vector                    24 bytes each   
Rotation                  28 bytes each

Keeping an Efficient Visitor List etc.

Storing UUIDs in a list is frightfully inefficient as the figures above for holding keys in lists in Mono show, even if storing them as strings helps a bit (keys 102 byte per entry, strings 90 bytes per entry). So I decided to look at other ways of storing identifications of visitors to a SIM etc. One way would be to use uuid compression routines, as can be found in this Wiki. However I recently analysed over 1300 legacy avatar names (which, by design, have to be unique) and found that the average name was 11.5 character long (after stripping " Resident" off any such names). So, as strings require 18 bytes overhead plus 2 bytes per character as a list entry, each name on average would require 41 bytes of list space, enabling over twice as many avatars to be held in a list compared to holding UUIDs, with almost no scripting overhead. Of course, if you must have UUIDs this won't help! But my remit was purely to find the number of individuals who visited a SIM. I hit a stack-heap collision after 1350 names were stored.