Tenho lido vários textos sobre o Mono e a velocidade que vai trazer para o SL. Por isso ontem decidi fazer um pequeno Hands-On Labs e ir eu mesmo testar para uma preview Grid.

Decidi criar um objecto com 220 Prims, tudo linkado, cubos simples para fazer ciclos de alterações de formatos das Linked Prims, com cálculos pelo meio, tudo para por peso nas operações. Resumindo, criei um Prim com o código principal com 220 linked prims. Meti o código no Prim principal e gravei Sem a Opção MONO no editor. Depois copiei o objecto - com os seus linked prims para um novo e compilei o código script com a opção mono.

Ambos objectos estavam com um Listen para iniciarem o teste assim que “ouvissem” a palavra “start”. Depois, o script fazia um ciclo de 2 até 220 e mudava as características dos Linked Prim através da função llSetLinkPrimitiveParams. Eu sabia que esta função tem um Delay de execução de 0.2, ou seja, por cada chamada à função eram aguardados sempre 0.2 segundos.

O código do primeiro teste era mais ao menos isto:

list mylist=[];
dothings(string msg)
{
integer total=(integer)msg;
if(total<1)
{total=223;}

integer i;
llSay(0,”Starting MONO”);
for(i=2;i < total;i++)

{
llSetLinkPrimitiveParams(i,[PRIM_TEXTURE, ALL_SIDES, "1dc12969-4a6e-4f3c-8c3a-b5355cef1293" , <1,1,1>, <1,1,1>, 0,PRIM_COLOR, ALL_SIDES, <1, 0, 0>,1.0]);

}

llSay(0,”Fim para o MONO” );

}

default
{
state_entry()
{

mylist=[];
llListen( 0, “”, NULL_KEY, “” );
}

listen( integer channel, string name, key id, string message )
{
if (message==”start”)
{
dothings(message);
}
}
}

Neste primeiro o resultado ficou pouco favorável a quem aguarda pelo Mono. Ou seja, os dois testes demoraram exactamente o mesmo tempo de execução. Não cronometrei este primeiro teste, mas via os LinkedPrim a mudarem de cor e textura um a um e terminaram exactamente ao mesmo tempo.

Conclusão deste primeiro ensaio: sem cálculos ou grandes instruções internas com listas, ciclos, etc, o Mono não vai trazer grande vantagem, mas claro, em Scripts simples como este.

Tive então que adicionar mais cálculos para por peso no teste. Adicionei então uma função que, por cada ciclo dos 220 chamasse uma outra que fizesse outro ciclo de 1 até ao valor vindo do primeiro ciclo, somando dentro desse, os valores e adicionado posteriormente o total a uma Lista.

Criei este código, então, para por peso nos cálculos.

empata(integer y)
{
integer i;
integer total=y;

integer soma=0;
for(i=0;i < total;i++)
{
soma+=i;
}
mylist=mylist+[soma];

}

E no fim da instrução llSetLinkPrimitiveParams chamava sempre a função envolvida: empata(i);Ou seja, o valor I era enviada para a função empata que executava um ciclo de 1 até I, somando sempre os valores (1...N) e adicionado o resultado à Lista. Por exemplo, se I fosse 4 era executado o ciclo de 0 até 3, com o resultado de 0+1+2+3=6 adicionado 6 à Lista.

Quando executei o código no início as coisas pareceram que iam correr igual com ligeiro avanço do Mono, mas passados poucos segundo, quando o ciclo da função Empata foi aumentando, o mono começou a avançar muito mais rapidamente. cada vez mais rápido.

O resultado final foi:

MONO completou em: 50 Segundos
LSL completou em: 2 Minutos e 10 Segundos - quase 3 vezes mais lento.

Conclusão a que cheguei ? a que já esperava…quanto mais pesados os cálculos internos dos Script maior será a diferença entre Lsl e lslMono. Este meu teste mostrou com pouco código uma velocidade de cerca de 3 vezes superior, favorável ao Mono, mas já há testes com cálculos matemáticos bem mais complexos que atingiram velocidades até 200 vezes maiores.

Como é evidente isto não é nenhum “Whitepaper” e estes testes valem o que valem. Fi-lo para tirar algumas dúvidas que eu tinha em relação ao Mono e os scripts que criei foram simples e não abrangeram a maior parte dos tipos de interacções dos Scripts com LsL, por exemplo os movimentos, rotações, etc… mas a ideia, para mim pelo menos, ficou mais clara: venha o LsLMono.

Em baixo a imagem do teste, do lado esquerdo feito com LsL e à direita LslMono: