So Kokiri Saarinen and I just spent a very geeky couple of hours testing Mono list storage capacity (and, sadly enough, competing for the fastest result times) and we accidentally discovered something odd:
Casting keys as strings allowed us to store 13x as much data.
We ran different tests, with different configurations, compiling the lists in different ways, for a solid hour, and kept arriving at the same results: a key, stored in a list as a key, ate 106 bytes. The same key, casted to a string, ate 8 bytes. We were able to create a list of 7692 (under ideal circumstances) 36-character strings (keys converted to strings) before the script ran out of memory and stack-heaped, but only 583 keys.
This is pretty odd, and I’m not yet ready to declare that conclusive, as that’s a rather huge discrepancy. List memory usage in Mono is supposed to be calculated thusly:
string: 22 + 1 byte per character
key: 34 + 1 byte per character
So while strings should be a little bit more memory-efficient, they should still eat nearly 60 bytes. Why, then, the script would be storing them as 8 bytes is beyond me.
These tests all stored a global list and ran a loop adding keys to the list (with results displayed via llSetText) until the script barfed up a stack-heap collision.
If anybody else who has more knowledge about LSL memory would like to enlighten me, I’d love to hear it.
Luc Aubret is the Creative Director in charge of product development for
Anybody who just wants to comment on the dubious likelihood of me ever getting laid when something like this interests me, however, can keep their opinions to themselves.
That is rather curious. Since a key and a string are, in effect, the same exact thing.
It might have to do with the lsl compiler’s buit in ability to typecast a key as a string on the fly.
Although the compiler cannot implicitly typecast a key to a string, it can typecast a string as a key.
Sounds like this could be the remains of an attempt at a key to string typecasting system. Since when they are in a list they are treated as the same generic data type.
8 bytes? I would think that the 32 hex digits of the key would require a minimum of 16 bytes.
Did you test this in both MONO and the original compiler? It could have something to do with MONO’s compiling abilities.
When you tried to recast your casted ’string key’ back to a key… did it return the right value? You did check that right?
Of course.