Quelle est la différence de vitesse entre les langues DLR et C # dans Silverlight 2?

Question

Pour Silverlight 2, il semble que les choix de programmation soient:

• C #
• VB
• Langages de script DLR
  • IronRuby
  • IronPython
  • jScript géré tristement négligé (sinon annulé)

S'agit-il d'un cas où les langues natives (C # et VB) sont plus rapides que les langues DLR d'un ordre de grandeur ou à peu près?

Tout espoir de "vivre" dans IronPython lorsque je fais de la programmation client Silverlight, ou devrais-je m'attendre à passer en C # pour un travail gourmand en ressources processeur?

Mon enquête sur les langues provient de cet ensemble d'exemples pour C # et VB et cette page sur le DLR .

Answer 1

Malheureusement, il n’ya pas de réponse définitive à cette question. Les performances d'une même langue varient considérablement en fonction d'un certain nombre de paramètres.

Oui, en général , VB.Net et C # seront plus rapides que les langages DLR. Les langages statiques font plus de travail au moment de la compilation, tels que la liaison de méthodes. Ce type de travail doit être effectué au moment de l'exécution pour les langages basés sur le DLR, ce qui entraîne un coût légèrement plus élevé au moment de l'exécution.

Cependant, l'optimisation des langages DLR et DLR nécessite beaucoup de travail. Une grande partie de ce travail est atténuée par diverses caches et ainsi de suite. Dans de nombreux types d'applications, la différence de performances sera négligeable.

Je ne voudrais pas exclure un langage basé sur DLR basé uniquement sur les performances, à moins qu'un profileur ne me dise que c'est en réalité un problème.

Answer 2

Généralement, l'optimisation d'un algorithme aura un effet beaucoup plus important que la réécriture dans un langage statique.

Vous pourriez être intéressé par Afficher n ° 429 de .NET Rocks, une interview avec Michael Foord. Voici un extrait pertinent de la transcription :

  

Les langages dynamiques sont beaucoup plus faciles à utiliser   test, ils sont vraiment adaptés à la   Approche de développement piloté par les tests qui   les développeurs prenaient à ce   temps. Mais j'ai supposé que pour   raisons de performance, ils auraient   réécrire en C # à un moment donné, et   puis trois ans et un peu plus tard, nous   a 40 000 lignes de code IronPython,   nous avons environ 140 000 lignes dans un   code de test, nous avons un certain type de   environ 300 lignes de C # et à chaque fois   ils viennent regarder la performance,   chaque fois qu'ils viennent et ont dit localiser   une opération qui ne marche pas vite   assez, nous avons pu obtenir le   la vitesse dont nous avons besoin en améliorant notre   algorithmes, en améliorant notre Python   code et ne pas avoir à tomber dans C #,   et les programmes de raisons fonctionnent lentement   généralement pas la faute de la langue,   c'est la faute du programmeur, le   développeur.

Answer 3

Vous pouvez aussi utiliser Boo. Voici un échantillon / a>