LSL Mono : inefficient heap memory management?

[clevertricks]

Hi Linden people ?

 

1- SUMMARY

 

I have performed a memory benchmark on LSL Mono scripts (see below for details).

It shows that on average, for each global variable of type integer, more than 22 bytes are consumed from the script memory.

22 bytes is a lot, compared to the actual integer payload (4 bytes).

Considering that LSL Mono scripts have only 64K bytes available, it would be nice to spare them...

 

- What accounts for the 20+ bytes per integer?

- Is there a way to reduce this memory consumption ?

 

2- BENCHMARK CODE

 

The benchmark is very simple :

 

integer i1;

integer i2;

integer i3;

...

integer i<N-1>;

integer i<N>;

 

default

{

    state_entry()

    {

        llOwnerSay((string) llGetFreeMemory());

    }

}

 

3- BENCHMARK RESULTS

 

 

N	llGetFreeMemory()	Comments
0	62172
1	62164	2 bytes for integer i
2	62164	0 byte for i2
3	62156	2 bytes for i3
4	62156	0 byte for i4
5	62148	8 bytes for i5
6	62148	0 byte for i6
...
10	62132
11	61612	520 BYTES FOR i11!!!
12	61612	0 byte for i12
13	61604	8 bytes for i13
14	61604	0 byte for i14
15	61596	8 bytes for i15
16	61596	...
17	61588
18	61588
...
38	61508
39	61508
40	60988	512 BYTES FOR i40!!!
...
1000	40252	21.9 byte average per integer
2000	17308	22.4 byte average per integer
2742	4	22.7 byte average per integer
2743	heap stack collision

 

 

4- TENTATIVE ANALYSIS

 

Because global variables have to be re-initialized on script reset, I suspect Mono keeps a copy of the initial value in memory. This would account for 8 bytes per integer.

 

The fact that free memory decreases by about 512 bytes with integers i11 and i40 (in the benchmark) suggests that i11 and i40 have resulted in an increase of the script's code size (in SL LSL, memory for code increases by chuncks of 512 bytes).

 

Thus I suspect that for each global variable, in addition to the above-mentioned 8 bytes, the Mono compiler adds code to the script, to re-initialize the value of the variable on script reset.

 

Still, 22 bytes per integer is an awful lot.

For example, for un-assigned global integers (such as in the benchmark code), a simple loop assigning value 0 should suffice.

 

Suggestions, anybody?

 

Edited October 8, 2018 by clevertricks