CajuScript 0.3.5

This message was edited 1 time. Last update was at 27/02/2009 18:44:12

neófito wrote:

Na minha máquina, o resultado foi:
Groovy: 516ms - 3000
Caju: 375ms - 3000
O que não é uma diferença tão grande assim, não acha?

eduveks wrote:Quanto ao resto das coisas que você diz dispenso comentar, acho que não vale a pena.

Sinto muito, mas isso só mostra que você não sabe manter uma discussão civilizada.

Não é uma diferença muito grande? 28% mais rápido não é muito grande? Mais que 1/4 mais rápido. Pra mim continua sendo mais vantagioso.

Mas como ja disse vai de cada um, CajuScript tem os recursos que tem, e estamos fazendo o melhor para melhora-lo, o Groovy tem o poder que tem, para certos cenários um é mais indicado que outro!

E olha ainda bem que o Groovy ficou mais rápido neste testes, por que me assustava aquele resultado grotesco.

Este foi um teste isolado, mas há inumeras situações, dependendo do contexto o CajuScript pode se tornar muito vantagioso.

E na boa, faz este teste em Java e veja bem o resultado, se chegar a 5ms é muito! Groovy performance próxima da do Java é um argumento completamente sem base, queria ver testes que comprovem isto, que só vc falando e pelos resultado que vi do Groovy até agora não me parecem nada próximo do Java.

Acho que não devemos mais discutir performance, pois se para ti 28% não quer dizer nada, e que o Groovy tem quase a mesma performance do Java, então podemos ficar por aqui.

Uma coisa sei, CajuScript tem me aberto portas excelentes de negócio, tenho clientes que ganho de 5% já faz muita diferença. Tudo depende das exigências dos projetos/clientes. Se um dos meus projetos ficasse 28% mais lento seria uma desgraça.

JavaTeenager Membro desde: 26/07/2005 09:35:10 Mensagens: 156 Offline

Parabens eduveks, pelo projeto e tambem por se preocupar com a performance.

Quanto aos recursos, tenho certeza que primando pela velocidade, quando voce implementar

o que tem seus concorrentes, seu soft sera' a melhor opcao disparado.

Continue Assim !!!

Quando eu tiver um tempo aqui , verei com mais calma seu produto.

j-menezes wrote:Parabens eduveks, pelo projeto e tambem por se preocupar com a performance.

Quanto aos recursos, tenho certeza que primando pela velocidade, quando voce implementar

o que tem seus concorrentes, seu soft sera' a melhor opcao disparado.

Continue Assim !!!

Quando eu tiver um tempo aqui , verei com mais calma seu produto.

Muito obrigado pelo apoio e compreensão.

A nossa preocupação e o nosso plano é exatamente isso. Penso que a barreira da performance é a mais crítica e temos vencido, o resto virá com o tempo.

eduveks wrote:Não é uma diferença muito grande? 28% mais rápido não é muito grande? Mais que 1/4 mais rápido. Pra mim continua sendo mais vantagioso.

Não é uma diferença tão grande quanto à que você havia dito antes. Lá o groovy estava demorando 7 segundos, o que é absurdo. Agora a diferença foi de 141ms, bem menos do que antes. E 28% mais lento mas com recursos como metaprogramming, que torna as coisas mais lentas. Só quero ver como estará a performance do cajuscript quando ele chegar perto dos recursos do groovy.

eduveks wrote:E olha ainda bem que o Groovy ficou mais rápido neste testes, por que me assustava aquele resultado grotesco.

O resultado grotesco foi devido à sua falta de conhecimento sobre a linguagem.

eduveks wrote:E na boa, faz este teste em Java e veja bem o resultado, se chegar a 5ms é muito! Groovy performance próxima da do Java é um argumento completamente sem base, queria ver testes que comprovem isto, que só vc falando e pelos resultado que vi do Groovy até agora não me parecem nada próximo do Java.

Você não sabe ler? Ou simplesmente ignorou o que eu escrevi em um post anterior? Bom, vou escrever novamente para que fique claro:

neofito wrote:Realmente me expressei mal quando disse que o código rodava próximo a performance do java. Na verdade, o que quis dizer, é que o groovy não faz muitas coisas além do que o java na execução de um loop, por isso não há porque dizer que o loop do groovy é muito mais lento do que o java.

This message was edited 8 times. Last update was at 02/03/2009 21:24:40

neófito wrote:

eduveks wrote:E na boa, faz este teste em Java e veja bem o resultado, se chegar a 5ms é muito! Groovy performance próxima da do Java é um argumento completamente sem base, queria ver testes que comprovem isto, que só vc falando e pelos resultado que vi do Groovy até agora não me parecem nada próximo do Java.

Você não sabe ler? Ou simplesmente ignorou o que eu escrevi em um post anterior? Bom, vou escrever novamente para que fique claro:

neofito wrote:Realmente me expressei mal quando disse que o código rodava próximo a performance do java. Na verdade, o que quis dizer, é que o groovy não faz muitas coisas além do que o java na execução de um loop, por isso não há porque dizer que o loop do groovy é muito mais lento do que o java.

"por isso não há porque dizer que o loop do groovy é muito mais lento do que o java" !? Ou seja volta a afirmar sutilmente! Não há por que dizer realmente, é só um fato! Vc apenas quiz indiretamente dizer que loop em Groovy é tão rápido quanto em Java. O que não é verdade nem de longe. E realmente se expressou mau e continua...

Quanto ao resto, me resumo a perguntar... nos testes foi usado em algum momento metaprogramming? Se são loops simples onde entra os outros recursos que debilitam a performance?

Meu caro, como eu já disse, é tudo uma questão de gosto, em alguns cenários o CajuScript tem performance superior, tendo ou não mais ou menos recursos, se isto é útil para vc maravilha! Se não não há por que usar o CajuScript.

Em nenhum momento disse que o CajuScript é melhor que o Groovy, apenas CajuScript é sim mais rápido que o Groovy em alguns cenários, como os usados nos testes, por isso fazemos questão de mostrar o código usado nos testes, para que também possam nos chamar atenção se estamos fazendo alguma coisa errada para realizar os testes mais justos possíveis.

Por isso se vc não entendeu ainda, e já faz tempo que não vejo razão para tanta discussão, quando outras pessoas já compreenderam o propósito, menos tu até agora, é que o CajuScript propõe ser rápido, logo se um dia implementarmos closures ou metapramming e isto prejudicar a performance, dificilmente vamos fazer, vamos sim tentar fazer outras coisas para compensar isto.

O principal objetivo do CajuScript é manter a performance, para cenários que exigem isto! Como é o caso da área em que trabalho, que com certeza não é a mesma que a tua, por isso Groovy é excelente para ti e CajuScript é o único que me serve. Se o teu projeto se encaixa melhor com um ou com outro cabe a ti melhor decidir. Se conta performance ou recursos.

Agora que vamos tentar implementar a maioria dos recursos vamos, se vai prejudicar a performance vamos ver, e no futuro poderemos falar melhor sobre isto. Mas para mim especialmente se o CajuScript tiver ou não suporte a tantos recursos pouco importa, o que importa é ser dinâmico e rápido.

De uma vez por todas os testes de comparação do CajuScript só serve demonstrar que é mais rápido em alguns cenários, claro que basta 5 minutos vendo a documentação para ver que CajuScript não tem tudo que o Groovy e Ruby e etc oferecem, por isso o CajuScript ser mais rápido? Talvez! É apenas claro que se tens problema de performance e precisa de algo dinâmico CajuScript pode ser opção.

Pensava que tudo isto era bem óbvio, mas acho que expliquei da maneira mais detalhada que pude para ver se fica bem compreensivel.

E outra eu poderia dizer N cenários onde justificaria o testes em que o Groovy levou 7 segundos como real e justo, pois em um ambiente multithread por exemplo onde por alguma razão eu não posso reaproveitar a mesma instancia do Groovy por algum motivo, ai como contornaria para baixar os 7 segundos? Compilar o script? Mas se também eu não puder compilar o script por ser um script gerado dinâmico por exemplo? Nestas condições pode haver vários fatores em que favorece o uso do CajuScript.

Então para complicar a vida do Groovy, mas usando a mesma instancia para não complicar tanto. E se eu tivesse dois ou N scripts, diferentes claro, para serem executados em loop dependendo de algumas condiçoes, ai em vez de 7 segundos levaria quanto? 14 segundos? Ou mais? Pois o teste foi com apenas um script.

Só pensar um pouco e podera ver onde o CajuScript pode ser aplicado com sucesso, cada um no seu quadrado, cada um com o seu ponto forte. E somos todos felizes.

JavaTeenager Membro desde: 26/07/2005 09:35:10 Mensagens: 156 Offline

neófito, a forma como voce implementou o exemplo do Groovy para diminuir a lentidao, voce desviou de uma coisa
muita importante pra quem desenvolve que e' a naturalidade do codigo.

o resultado disso e' um programa mais confuso, basta ver o exemplo do eduardo e o seu.

Sei bem o que e' esse negocio de performance, sem querer falar bem o mal de quem quer que seja

vou narrar a minha experiencia.

Tive serios problemas com RMI da Sun, era rapido e continua sendo em ambiente intranet por exemplo, todavia
tem muitos problemas como o servidor visualizar o callback de um cliente que esteja roteado, rodar num servidor
com um IP valido de internete e etc etc...
Entao vi aqui mesmo no forum uma nova e BOA implementacao do LipeRMI, entao resolvi usar e resolveu meus problemas
do RMI da SUN mas ........

Ficou cerca de 3 vezes mais lento que o da SUN em intranet, e no meu sistema DESKTOP a diferenca apareceu
coisa que ele fazia em 800 ms com o da SUN o do lipeRMI fazia em 2,8 segundos, como o usuario fica esperando
a resposta entao percebe-se.

Entao fiquei pensando como resolver, abri o codigo do LipeRMI pra estudar e resolvi fazer outra implementacao.

Resultado, consegui colocar os mesmos recursos do LipeRMI e nos meus testes aqui tem momentos que bate o
da SUN em performance , consegui em 600 ms.

Entao, nao e' como voce coloca as coisas, tem horas que performance conta SIM.

E quem precisa dela Sabe Disso.

Outra coisa, 28% de diferenca ainda com todo o malabarismo que voce fez no Groovy e' muita coisa.

This message was edited 3 times. Last update was at 02/03/2009 21:26:58

pois é j-menezes...

só quem já teve problemas de performance sabe como é... profilers e mais profilers.

eu passo a vida lutando contra isto! mas é gratificante d+ quando conseguimos bons resultados! Isto não tem preço

eduveks wrote:
Agora se querem dizer que o CajuScript tem menos recursos que o Groovy e por isso é mais rápido. Isto não é verdade. O que o Groovy faz num loop por exemplo? Por que ele demora tanto a inicializar? Isto são problemas básicos que o CajuScript já tem ultrapassado, mas normalmente é por que a maioria das linguagens de script usam parsers e interpretadores de terceiros, no CajuScript foi feito tudo do zero, a medida, isto nos da muito mais liberdade para fazermos o que quisermos, e por isso também conseguimos fazer a sintaxe dinâmica.

Por exemplo o Marcos fez este recurso:

http://code.google.com/p/cajuscript/wiki/tutorialOperable

Para ajuda-lo a realizar calculos em 2D e 3D, ele viu o projeto, foi ver o código para ver se dava para fazer isto, e em poucas horas me mandou esta idéia!

Você consegue ter esta facilidade em outros motores?

Marcos = "Mark_Ameba" ^^
E foi bem fácil implementar isso.

E estou afim de ajudar mais no projeto, para falar a verdade, da outra vez eu acabei desestindo de ajudar por não me entender direito com CVS/SVN (Não lembro qual usava).

Alias.. eu vi algo nos códigos(Todas as classes praticamente) que pode ser alterado por um pequeno ganho de performance.. vou testar depois eu coloco lá.

Notícias, artigos e o maior fórum brasileiro sobre Java