Является ли код С# быстрее, чем код Visual Basic.NET?

Является ли код С# быстрее, чем код Visual Basic.NET, или это миф?

Ответы

Ответ 1

Это миф. Они скомпилируются с той же CLR. Однако компилятор для одной и той же процедуры может немного отличаться в CLR. Таким образом, для некоторых подпрограмм некоторые из них могут быть немного лучше (на 0.0000001%) быстрее на С# и наоборот для VB.NET, но они оба убегают от одной и той же общей среды выполнения, поэтому оба они одинаковы в производительности, когда они рассчитывают.

Ответ 2

Единственная причина, по которой тот же код в vb.Net может быть медленнее, чем С#, заключается в том, что VB по умолчанию имеет checked арифметику, а С# не.

По умолчанию проверяются арифметические операции и переполнения в Visual Basic; в С#, это не так.

Если вы отключите это, то получившийся ИЛ, вероятно, будет идентичным. Чтобы проверить это, возьмите свой код и запустите его через Reflector, и вы увидите, что он выглядит очень похожим, если вы переключаетесь с С# на vb.Net-представления.

Возможно, что оптимизация (или просто различие в поведении) в компиляторе С# по сравнению с компилятором vb.net может привести к тому, что вы немного одобряете другое. Это:

  • Вряд ли будет значительным
    • Если бы это было, это было бы плохо висит фрукты, чтобы исправить.
  • Вряд ли произойдет.
    • С# и абстрактные синтаксические деревья vb.net очень близки по своей структуре. Вы можете автоматически транслитерировать большое количество vb.Net в С# и наоборот. Более того, результат будет иметь хорошие шансы выглядеть идиоматическим.

Есть несколько конструкций в С#, но не в vb.net, таких как небезопасные указатели. Там, где они используются, они могут дать некоторые преимущества, но только если они были фактически использованы и использовались надлежащим образом. Если вы придерживаетесь такой оптимизации, вам следует провести сравнительный анализ.
Честно говоря, если он делает большую действительно большую разницу, тогда вопрос не должен быть "Какой из С#/vb.net я должен использовать", вы должны вместо этого спрашивать себя, почему вы не переместите код на С++/CLI.

Единственный способ, которым я мог думать о том, что разные компиляторы могут ввести серьезные, всепроникающие различия, - это если вы решили:

  • Реализация хвостовых вызовов в разных местах
  • Реализованные блоки итератора или анонимные лямбды значительно эффективнее.
    • Я считаю, что оба компилятора примерно так же эффективны на высоком уровне, как и в этом плане. Оба языка нуждаются в явной поддержке стиля "yield foreach", доступного для генераторов последовательности f #.
  • В штучной упаковке, если это не было необходимо, возможно, не используя ограниченный код операции
    • Я никогда не видел, чтобы это произошло, но мне понравился бы пример, где он это делает.

Оба компилятора С# и vb.net в настоящее время оставляют такие сложности оптимизации, как en-registering переменных, вызывая соглашения, встраивание и разворачивание полностью до общего JIT-компилятора в среде CLR. Скорее всего, это повлияет на все остальное (особенно когда 32-разрядная и 64-битная JIT теперь могут вести себя совершенно по-другому).

Ответ 3

Структура написана на С#, но это все еще не говорит о различиях в производительности между С# или VB, поскольку все скомпилировано на IL-язык, который фактически выполняется (включая JITted и т.д.).

Ответственность за каждый конкретный язык компилятора заключается в том, что какой IL они производят на основе исходного кода. Если другой компилятор создает более подходящий IL, чем другой, тогда он может иметь разницу в производительности. Я точно не знаю, что есть такие области, где они могут вызвать радикально разные ИЛ, но я сомневаюсь, что различия все равно будут огромными.

Другим аспектом является полностью способность С# запускать небезопасный код, например, с использованием необработанных указателей и т.д., которые могут дать производительность по специальным сценариям.

Ответ 4

В оптимизации компилятора может быть небольшая разница, но я бы сказал, что нет заметной разницы. Оба С# и VB.NET скомпилируются под Common Intermediate Language. В некоторых случаях вы можете получить значительное увеличение производительности на С#, используя небезопасный код, но в большинстве случаев я бы не рекомендовал делать это. Если вам требуется что-то критическое, вы не должны использовать С#.

Миф, вероятно, начался из-за различий огромных в производительности Visual Basic 6 по сравнению со средним С++-приложением.

Ответ 5

Я был на конференции Microsoft, и сотрудники MS заявили, что С# до 8% быстрее, чем VB.NET. Так что, если это миф, он был запущен людьми, которые работают в MS. Если я смогу найти слайды, которые утверждают это, я бы опубликовал их, но это было тогда, когда вышел С#. Я думаю, что даже если бы это было верно в какой-то момент времени, единственная причина, по которой один был быстрее, чем другой, - это то, как все настроено по умолчанию, как сказал ShuggyCoUk.

Ответ 7

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

Однако VB.Net поставляется с библиотекой совместимости для программистов, используемых для VB6. Я вспоминаю о тех строковых методах, которые ожидали бы левые, правые, средние, старые программисты VB. Эти функции строковой манипуляции работают медленнее. Я не уверен, что вы заметили бы воздействие, но в зависимости от интенсивности их использования, я бы сказал, что ответ будет да. Почему эти методы медленнее, чем "родные".net-методы? Потому что они менее безопасны по типу. В принципе, вы можете бросить на них почти все, и они будут пытаться делать то, что вы хотите, как в старом VB6.

Я думаю о манипуляциях с строкой, но если я буду думать сложнее, я уверен, что я вспомню о других методах, брошенных в этот уровень совместимости (я не помню имя сборки, но помню, что по умолчанию она ссылается VB.Net), которые будут иметь влияние на производительность, если они используются вместо их .net "родного" эквивалента.

Итак, если вы продолжаете программировать, как в VB6, то вы можете заметить влияние. Если нет, это нормально.

Ответ 8

Есть несколько небольших отличий в сгенерированном коде, который может сделать С# несколько быстрее в некоторых ситуациях. Например, VB.NET имеет дополнительный код для очистки локальных переменных в методе, а С# - нет.

Однако эти различия едва измеримы, и большинство кода настолько далеки от оптимального, что вы только начинаете с неправильного завершения, переключая язык, чтобы сделать код быстрее. Вы можете взять практически любой интенсивный код процессора и довольно легко сделать его в два раза быстрее. Некоторый код можно сделать в 10 раз быстрее, другой код, возможно, в 10000 раз быстрее. В этом контексте несколько процентов, которые вы можете получить с помощью С# вместо VB.NET, не стоят усилий.

С другой стороны, обучение С# вполне может быть эффективным способом ускорения вашего кода. Не потому, что С# может генерировать более быстрый код, а потому, что вы лучше понимаете как С#, так и VB.NET, позволяя вам писать код, который лучше работает на любом языке.

Edit:
Компиляторы С# и VB.NET, очевидно, развиты более или менее синхронно. Разница в скорости между С# 1 и С# 2 составляет примерно 30%, разница между параллельными версиями С# и VB.NET намного меньше.

Ответ 9

Это не миф. В то время как С# и VB.Net объединяются в IL, фактические подготовленные команды, вероятно, будут отличаться, потому что 1. у компиляторов могут быть разные оптимизации и 2. дополнительные проверки, которые VB.Net делает по умолчанию, например. арифметическое переполнение. Поэтому во многих случаях производительность будет такой же, но в некоторых случаях С# будет быстрее. Возможно также, что VB.Net может быть быстрее в редких случаях.

Ответ 10

С# и VB.Net скомпилированы IL. Также скомпилированы С++ и F #. Фактически, четыре упомянутых мной языка исполняются с одинаковой скоростью. В этом "более быстром языке" нет разницы: уникальная разница между автоматически загружаемыми мусором языками (С#, VB.Net, F # и т.д.), И они не собираются автоматически (например, С++). Эта вторая группа, как правило, медленнее, потому что редко разработчик знает, как и когда собирает мусор в куче памяти, однако, если вы будете проинформированы о кучевой памяти, программа может быть быстрее, если на С++. Программы жесткой графики обычно производятся на С++ (например, большинство программ Adobe). Вы также можете вручную собрать мусор в С# (System.GC.Collect();) и в VB.Net(System.GC.Collect). Я знаю, что этот ответ не полностью увязан с вопросом, но я хочу предложить вам много способов и вариантов. Вы выбираете правильный путь для своих программ.