Какая разница в скорости между языками DLR и C # в Silverlight 2? - PullRequest
Новая
       17

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

0 голосов
/ 21 июня 2009

Для Silverlight 2 похоже, что варианты программирования:

  • C #
  • VB
  • Языки сценариев DLR
    • IronRuby
    • IronPython
    • К сожалению, пренебрегают (если не отменено) Управляемый JScript

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

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

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

Ответы [ 3 ]

11 голосов
/ 21 июня 2009

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

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

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

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

3 голосов
/ 23 июня 2009

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

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

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

1 голос
/ 24 июня 2009

Также вы можете использовать Boo. Вот образец Тетрис Silverlight с бу

...