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^y;                  4
x=~x;                 5
x=-x;                 5
x==y;                 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^1;                  8
x!=y;                 8
x=-~-~x;              8     equates to x+=2
x=-9;                 9     Oh !!   Does it load a +9 then negate it?
x==1;                 9
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
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

Test equality 
x==y;                 5
x==1;                 9

Test inequality
x!=y;                 8
x^y;                  4
x!=1;                 12
x^1;                  8

List storage Requirements in Mono

These figures differed from those that had been shown on http://wiki.secondlife.com/wiki/LSL_Script_Memory. I've now updated that page to reflect these findings.

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

Getting the length of a local list

len = llGetListLength(MyList)--------44 bytes ... independent of length of list

len = (MyList != [] )------------------14 bytes ... but 2.5 times slower than llGetListLength()

Auto-casting of integers to floats

  llSetTimerEvent(0)  is 3 bytes shorter than llSetTimerEvent(0.0);
  llSetText(message, <1, 1, 1>, 1) is 12 bytes shorter than llSetText(message, <1.0, 1.0, 1.0>, 1.0)

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.

I've just developed a means of storing a key losslessly in a quarternion, with help from work by Strife and Pedro. So that gives the chance to hold keys accurately in a list at just 28 bytes per key. Watch this space!