Qual é a diferença de velocidade entre os idiomas DLR e C# em Silverlight 2?

Question

Para Silverlight 2, parece que as opções de programação são:

• C#
• Vb
• DLR Script Languages
  • IronRuby
  • IRONPYTHON
  • Um JScript administrado tristemente (se não cancelado)

Este é um caso em que os idiomas nativos (C# e VB) são mais rápidos que os idiomas DLR por uma ordem de magnitude ou mais?

Alguma esperança de "viver" em Ironpython quando faço a programação do Silverlight Client, ou devo esperar cair no C# para um trabalho intensivo em processador?

Minha pesquisa com idiomas vem de Este conjunto de exemplos para C# e VB e Esta página discutindo o DLR.

Answer 1

Infelizmente, não há resposta difícil e rápida para esta pergunta. O desempenho do mesmo idioma varia muito baseado em vários parâmetros.

Sim, em em geral VB.NET e C# serão mais rápidos que os idiomas baseados em DLR. Línguas estáticas fazem mais trabalho no tempo de compilação, como a ligação do método. Esse tipo de trabalho deve ser feito em tempo de execução para idiomas baseados em DLR e, portanto, eles têm um pouco mais de custo em tempo de execução.

No entanto, muito trabalho é otimizando os idiomas baseados em DLR e DLR. Grande parte deste trabalho é mitigada por vários caches e assim por diante. Em muitos tipos de aplicações, a diferença de desempenho será insignificante.

Eu não descartaria uma linguagem baseada em DLR baseada apenas no desempenho, a menos que um perfilador me dissesse que era realmente um problema.

Answer 2

Normalmente, otimizar um algoritmo terá um efeito muito maior do que a reescrita em um idioma estático.

Você pode estar interessado em Mostrar #429 de .Net Rocks, uma entrevista com Michael Foord. Aqui está um trecho relevante do transcrição:

Os idiomas dinâmicos são muito mais fáceis de testar, eles são realmente adequados para a abordagem de desenvolvimento orientada a testes que os desenvolvedores estavam adotando naquele momento. Mas eu assumi que, por motivos de desempenho, eles teriam que reescrever em C# em algum momento e, em seguida, três anos depois, recebemos 40.000 linhas de código de ferro, temos cerca de 140.000 linhas em um código de teste, nós temos Recebi algum tipo de cerca de 300 linhas de C# e toda vez que eles veem para analisar a performance, toda vez que vêm e diziam localizar uma operação que não está funcionando rápido o suficiente, conseguimos obter a velocidade de que precisamos melhorando nossos algoritmos , ao melhorar nosso código Python e não ter que cair no C#, e os programas dos programas lentos geralmente não é culpa do idioma, é culpa do programador, o desenvolvedor.

Answer 3

Você também pode usar o boo. Aqui está a amostra Silverlight Tetris com Boo