В чем разница в скорости между языками DLR и C # в Silverlight 2?

Для Silverlight 2, похоже, есть следующие варианты программирования:

  • C#
  • VB
  • DLR scripting languages
    • IronRuby
    • IronPython
    • К сожалению, запущенный (если не отменять) управляемый jScript

Это тот случай, когда родные языки (C # и VB) на порядок быстрее языков DLR?

Есть ли надежда на то, чтобы «жить» в IronPython, когда я занимаюсь программированием клиента Silverlight, или мне следует ожидать, что я перейду на C # для работы с интенсивным процессором?

Мой обзор языков взят из этого набора примеров для C # и VB и эта страница, на которой обсуждается DLR.


person Nosredna    schedule 20.06.2009    source источник


Ответы (3)


К сожалению, на этот вопрос нет однозначного и быстрого ответа. Производительность даже одного и того же языка сильно различается в зависимости от ряда параметров.

Да, в целом VB.Net и C # будут быстрее, чем языки на основе DLR. Статические языки выполняют больше работы во время компиляции, например привязку методов. Этот тип работы должен выполняться во время выполнения для языков на основе DLR, и, следовательно, они имеют немного больше затрат во время выполнения.

Однако много работы требуется для оптимизации языков, основанных на DLR и DLR. Большая часть этой работы смягчается различными кешами и т. Д. Во многих типах приложений разница в производительности будет незначительной.

Я бы не исключил, что язык на основе DLR основан исключительно на производительности, если только профилировщик не сказал мне, что это действительно проблема.

person JaredPar    schedule 21.06.2009
comment
Все это имеет смысл. Мне просто интересно, обнаруживают ли люди, использующие IronPython, больше написания C #, чем они ожидали. - person Nosredna; 21.06.2009

Обычно оптимизация алгоритма дает гораздо больший эффект, чем переписывание на статическом языке.

Возможно, вас заинтересует Show # 429 .NET Rocks, интервью с Майкл Форд. Вот соответствующий отрывок из расшифровки стенограммы:

Динамические языки намного легче тестировать, они действительно подходят для подхода к разработке через тестирование, который разработчики использовали в то время. Но я предполагал, что по соображениям производительности им придется в какой-то момент переписать на C #, а затем три с небольшим года спустя мы получили 40 000 строк кода IronPython, у нас есть около 140 000 строк в тестовом коде, у нас у нас есть около 300 строк C #, и каждый раз, когда они приходят посмотреть на производительность, каждый раз, когда они приходят и говорят, найдите операцию, которая работает недостаточно быстро, мы смогли получить нужную скорость, улучшив наши алгоритмы , за счет улучшения нашего кода Python и отсутствия необходимости опускаться до C #, и причины, по которым программы работают медленно, обычно не являются ошибкой языка, это ошибка программиста, разработчика.

person dahlbyk    schedule 22.06.2009
comment
За этой бородой скрывается много знаний IronPython ;-p - person Marc Gravell; 23.06.2009