Qual è la differenza di velocità tra le lingue DLR e C # in Silverlight 2?

Question

Per Silverlight 2, sembra che le scelte di programmazione siano:

• C #
• VB
• Linguaggi di scripting DLR
  • IronRuby
  • IronPython
  • Un jScript gestito tristemente trascurato (se non cancellato)

È un caso in cui le lingue native (C # e VB) sono più veloci delle lingue DLR di un ordine di grandezza o giù di lì?

Qualsiasi speranza di "vivere" in IronPython quando eseguo la programmazione client Silverlight o dovrei aspettarmi di passare a C # per un lavoro ad alta intensità di processore?

Il mio sondaggio sulle lingue proviene da questa serie di esempi per C # e VB e questa pagina che discute del DLR .

Answer 1

Sfortunatamente non esiste una risposta dura e rapida a questa domanda. Le prestazioni anche della stessa lingua variano notevolmente in base a una serie di parametri.

Sì, in generale VB.Net e C # saranno più veloci delle lingue basate su DLR. I linguaggi statici fanno più lavoro in fase di compilazione come il metodo binding. Questo tipo di lavoro deve essere eseguito in fase di esecuzione per i linguaggi basati su DLR e quindi hanno un costo leggermente maggiore in fase di esecuzione.

Tuttavia, molto lavoro viene svolto per ottimizzare i linguaggi basati su DLR e DLR. Gran parte di questo lavoro è mitigato da varie cache e così via. In molti tipi di applicazioni, la differenza di prestazioni sarà trascurabile.

Non escluderei un linguaggio basato su DLR basato esclusivamente sulle prestazioni a meno che un profiler non mi abbia detto che in realtà era un problema.

Answer 2

L'ottimizzazione in genere di un algoritmo avrà un effetto molto maggiore rispetto alla riscrittura in un linguaggio statico.

Potresti essere interessato a Show # 429 di .NET Rocks, un'intervista con Michael Foord. Ecco un estratto pertinente dalla trascrizione :

  

Le lingue dinamiche sono molto più semplici   test, sono davvero adatti per il   Test Driven Development si avvicina a questo   gli sviluppatori lo stavano prendendo in considerazione   tempo. Ma ho pensato che per   ragioni di prestazione, avrebbero   riscrivere in C # ad un certo punto, e   poi tre e un po 'di anni dopo   ottenuto 40.000 righe di codice IronPython,   abbiamo circa 140.000 linee in a   codice di prova, abbiamo un qualche tipo di   circa 300 righe di C # e ogni volta   vengono a vedere lo spettacolo,   ogni volta che vengono e dicono individuare   un'operazione che non funziona velocemente   abbastanza, siamo stati in grado di ottenere il   velocità di cui abbiamo bisogno migliorando il nostro   algoritmi, migliorando il nostro Python   codice e non dover cadere in C #,   e i motivi per cui i programmi funzionano lentamente   di solito non è colpa della lingua,   è colpa del programmatore, il   sviluppatore.

Answer 3

Inoltre puoi usare Boo. Ecco l'esempio / a>