Don't Count Your Mono Chickens Before They've Hatched

I've been telling people not to count too much on the performance gains of mono over the current LSL engine. It will probably be better, but not much. Also, the 64k memory is to make up for the fact that some of the data types are 4 times as big as in the 16k memory model, thus, in the degenerate case, a current 16k script will use 64k. One nice thing though is that scripts only have to allocate memory in mono in 4k blocks, meaning that small scripts will take up less memory, because the current engine always allocates 16k for a script no matter how little it uses.

People who like to be argumentative with me and disagree point to the blazing performance of mono for math operations with demonstrations like this:


While indeed an impressive demonstration, I would like to point out that not many scripts do tons of internal math calculations as their primary function. Most of them update objects in various ways, for which mono is actually a bit slower than the current engine for object updates:


While very close to the current engine in performance, it is still slower. For the bulk of operations, mono will be about the same performance as the current engine, perhaps faster. For some operations it will be much faster. For memory consumption, it will most likely be a wash, since there are lots of tiny scripts, but any substantial script will use more memory, and more communications bandwidth.

To quote from some empirical trials done by claudio pacchiega:

What surprised me was that the simple sequence:
(this mono is going to heavily surprise me :(

list lst=[]; integer i;
for(i=0;i<10000;i++)
{
if(i%10==0)llSay(0,(string)i+" "+(string)llGetTime());
lst+=(string)i;
}
appeared only 4-5 times faster in mono than in lsl2 (total iterations divided by total time),

I also did something like

str="18 characters"; list lst=[]; integer i;
for(i=0;i<10000;i++)
{
if(i%10==0)llSay(0,(string)i+" "+(string)llGetTime());
lst+=[str+str];
}
appeared only 2 times faster in mono than in lsl2.

To which the reply from Argent Stonecutter was:

These shouldn't be surprising. In this kind of code copying data dominates, and LSL is already doing that part in native code.

There are three kinds of lies: lies, damned lies, and benchmarks. Mono is going to be massively faster for raw arithmetic, which is well understood and heavily optimized in Mono and completely un-optimized in LSL. Conversely, LSL code that's mostly copying data and calling back to Havok or doing communications, that's not going to be much if any faster.

So, in short, while a 2-4 times improvement in script performance is a great achievement and I can't wait. Don't sit around and expect the 200 times performance some people have bandied about.