¿Cuál es la diferencia de velocidad entre los lenguajes DLR y C # en Silverlight 2?

Question

Para Silverlight 2, parece que las opciones de programación son:

• C #
• VB
• Lenguajes de script DLR
  • IronRuby
  • IronPython
  • Un jScript gestionado tristemente descuidado (si no cancelado)

¿Es este un caso en el que los idiomas nativos (C # y VB) son más rápidos que los idiomas DLR en un orden de magnitud más o menos?

Cualquier esperanza de "vivir" en IronPython cuando hago la programación del cliente Silverlight, ¿o debería esperar caer en C # para el trabajo intensivo en el procesador?

Mi encuesta de idiomas proviene de este conjunto de ejemplos para C # y VB y esta página discute el DLR .

Answer 1

Desafortunadamente no hay una respuesta rápida y difícil a esta pregunta. El rendimiento de incluso el mismo idioma varía mucho en función de una serie de parámetros.

Sí, en general VB.Net y C # serán más rápidos que los lenguajes basados ??en DLR. Los lenguajes estáticos hacen más trabajo en tiempo de compilación, como el enlace de métodos. Este tipo de trabajo debe realizarse en tiempo de ejecución para lenguajes basados ??en DLR y, por lo tanto, tienen un costo un poco más elevado en tiempo de ejecución.

Sin embargo, se necesita mucho trabajo para optimizar los lenguajes basados ??en DLR y DLR. Gran parte de este trabajo es mitigado por varios cachés, etc. En muchos tipos de aplicaciones, la diferencia de rendimiento será insignificante.

No descartaría un lenguaje basado en DLR basado únicamente en el rendimiento a menos que un perfilador me dijera que en realidad era un problema.

Answer 2

Normalmente, la optimización de un algoritmo tendrá un efecto mucho mayor que la reescritura en un lenguaje estático.

Puede que le interese Mostrar # 429 de rocas .NET, Una entrevista con Michael Foord. Aquí hay un extracto relevante de la transcripción :

  

Los lenguajes dinámicos son mucho más fáciles de usar   prueba, son realmente adecuados para el   Enfoque de desarrollo impulsado por pruebas que   los desarrolladores estaban tomando eso   hora. Pero supuse que por   razones de rendimiento, tendrían   reescribir en C # en algún momento, y   entonces tres y un poco más tarde nos   obtuve 40,000 líneas de código IronPython,   tenemos alrededor de 140,000 líneas en un   código de prueba, tenemos algún tipo de   alrededor de 300 líneas de C # y cada vez   vienen a ver la actuación,   cada vez que vienen y dicen localizar   una operación que no funciona rápido   suficiente, hemos podido obtener el   velocidad que necesitamos al mejorar nuestra   algoritmos, al mejorar nuestro Python   código y no tener que caer en C #,   y las razones por las que los programas se ejecutan lentamente es   generalmente no es culpa del idioma,   es culpa del programador, el   desarrollador.

Answer 3

También podrías usar Boo. Aquí hay una muestra