Код C# быстрее, чем Визуальный код Basic.NET? [закрытый]
Если Вы, используют Visual C++ 2005/2008, можно использовать проверенный дважды шаблон блокировки, с тех пор" , энергозависимые переменные ведут себя как заборы ". Это - самый эффективный способ реализовать лениво инициализированный одиночный элемент.
Singleton* GetSingleton()
{
volatile static Singleton* pSingleton = 0;
if (pSingleton == NULL)
{
EnterCriticalSection(&cs);
if (pSingleton == NULL)
{
try
{
pSingleton = new Singleton();
}
catch (...)
{
// Something went wrong.
}
}
LeaveCriticalSection(&cs);
}
return const_cast(pSingleton);
}
Каждый раз, когда Вам нужен доступ к одиночному элементу, просто назовите GetSingleton (). В первый раз, когда это называют, статический указатель будет инициализирован. После того, как это будет инициализировано, ПУСТАЯ проверка предотвратит блокировку для того, чтобы просто считать указатель.
НЕ ДЕЛАЮТ использование это на просто никаком компиляторе, поскольку это не портативно. Стандарт не делает гарантий о том, как это будет работать. Visual C++ 2005 явно добавляет к семантике энергозависимых для создания этого возможным.
необходимо будет объявить, и инициализируют КРИТИЧЕСКИЙ РАЗДЕЛ в другом месте в коде. Но та инициализация является дешевой, таким образом, ленивая инициализация обычно не важна.
9 ответов
Это миф. Они компилируются в одну и ту же среду CLR. Однако компилятор той же подпрограммы может работать в среде CLR несколько иначе. Таким образом, для некоторых подпрограмм некоторые могут быть немного лучше, например (0,0000001%) быстрее в C # и наоборот для VB.NET, но они оба работают в одной и той же общей среде выполнения, поэтому оба они одинаковы по производительности, где это важно.
Фреймворк написан на C #, но он все еще не говорит о различиях в производительности между C # или VB, поскольку все компилируется на язык IL , который затем фактически выполняется (включая JITted и скоро).
Каждый компилятор языка несет ответственность за то, какой тип IL они создают на основе исходного кода. Если другой компилятор создает более подходящий IL, чем другой, это может иметь разницу в производительности. Я точно не знаю, существуют ли такие области, где они могут вызвать совершенно разные ИЖ, но я сомневаюсь, что различия все равно будут огромными.
Другой аспект - это полностью способность C # запускать небезопасный код, например, с использованием необработанных указателей и т. Д., Что может дать производительность в особых сценариях.
Я был на конференции Microsoft, и сотрудники MS заявили, что C # до 8% быстрее, чем VB.NET. Так что если это миф, то это начали люди, которые работают в MS. Если бы я смог найти слайды, которые заявляют об этом, я бы опубликовал их, но это было тогда, когда C # только вышел. Я думаю, что даже если бы это было правдой в какой-то момент времени, единственная причина того, что один работает быстрее другого, - это то, как все настроено по умолчанию, как сказал ShuggyCoUk.
Обычно ответ таков, что это зависит ... Сам по себе, нет , VB.Net не медленнее, чем C #, по крайней мере, вы ничего не заметите. Да, будут небольшие различия в оптимизации компилятора, но сгенерированный IL будет по существу таким же.
Однако VB.Net поставляется с библиотекой совместимости для программистов, привыкших к VB6. Я вспоминаю о тех строковых методах, которые ожидали бы старые программисты VB влево, вправо, в середине. Эти функции обработки строк работают медленнее. Я не уверен, что вы заметите влияние, но, в зависимости от интенсивности их использования, готов поспорить, что ответ будет положительным. Почему эти методы медленнее, чем "собственные" строковые методы .net? Потому что они менее безопасны по типу. По сути, вы можете бросить в них что угодно, и они будут пытаться делать то, что вы от них хотите, точно так же, как в старом VB6.
Я думаю о манипуляциях со строками, но если подумать, уверен, что вспомню о других методах, добавленных на этот уровень совместимости (я не помню имя сборки, но помню на него по умолчанию ссылаются в VB.Net), которые могли бы повлиять на производительность, если бы их использовали вместо их «родного» эквивалента .net.
Итак, если вы продолжите программировать, как на VB6, вы можете заметить влияние . Если нет, ничего страшного.
Итак, если вы продолжите программировать, как в VB6, вы можете заметить влияние. Если нет, ничего страшного.
Итак, если вы продолжите программировать, как в VB6, вы можете заметить влияние. Если нет, ничего страшного.
На самом деле это не миф. Хотя и C #, и VB.Net компилируются в IL, фактические создаваемые инструкции, вероятно, будут разными, потому что 1. компиляторы могут иметь разные оптимизации и 2. дополнительные проверки, которые VB.Net выполняет по умолчанию, например, арифметическое переполнение. Поэтому во многих случаях производительность будет такой же, но в некоторых случаях C # будет быстрее. Также возможно, что в редких случаях VB.Net может работать быстрее.
Может быть небольшая разница в оптимизации компилятора, но я бы сказал, что заметной разницы нет. И C #, и VB.NET компилируются на Common Intermediate Language . В некоторых случаях вы можете получить значительный прирост производительности на C #, используя небезопасный код , но в большинстве случаев я бы не рекомендовал это делать. Если вам нужно что-то, что имеет решающее значение для производительности, вам также не следует использовать C #.
Миф, вероятно, возник из-за огромной разницы в производительности Visual Basic 6 по сравнению со средним приложением C ++.
Единственная причина, по которой один и тот же код в vb.Net может быть медленнее, чем в C #, заключается в том, что VB по умолчанию проверяет арифметику, а в C # нет .
По умолчанию в Visual Basic проверяются арифметические операции и переполнения; в C # их нет.
Если вы отключите это, результирующий IL, скорее всего, будет идентичным. Чтобы проверить это, возьмите свой код и запустите его через Reflector, и вы увидите, что он выглядит очень похоже, если вы переключитесь с представлений c # на vb.Net.
Возможно, что оптимизация (или просто разница в поведении) в c # По мнению компилятора, компилятор vb.net может привести к тому, что один будет немного лучше другого. Это:
- Вряд ли будет значительным
- если бы это было, исправлять было бы низко висящим плодом
- Маловероятно.
- Абстрактные синтаксические деревья C # и vb.net очень близки по структуре. Вы можете автоматически транслитерировать большую часть vb.Net в C # и наоборот. Более того, результат будет иметь хорошие шансы выглядеть идиоматическим.
В C # есть несколько конструкций, которых нет в vb.net, например, небезопасные указатели. Там, где они используются, они могут дать некоторые преимущества, но только в том случае, если они действительно используются и используются должным образом. Если вы дошли до такого рода оптимизации, вам следует провести соответствующие тесты.
Откровенно говоря, если это имеет действительно большую разницу, тогда вопрос не должен быть таким: «Какой из c # / vb.net мне следует использовать», вы должны вместо этого спрашивать себя, почему вы не переносите какой-то код на C ++ / CLI.
Единственный способ, которым я мог подумать о том, что разные компиляторы могут привнести серьезные, всеобъемлющие различия, - это если кто-то выберет:
- Реализовать хвостовые вызовы в разных местах
- Они могут ускорить или замедлить работу и, безусловно, повлияют на глубоко рекурсивные функции. Компилятор 4.0 JIT на всех платформах теперь будет учитывать все инструкции хвостового вызова, даже если для этого ему придется проделать большую работу .
- Реализованы блоки итератора или анонимные лямбда-выражения значительно эффективнее.
- Я считаю, что оба компилятора настолько же эффективны на высоком уровне, насколько они собираются получить в этом отношении. Оба языка потребуют явной поддержки стиля yield foreach, доступного для генераторов последовательности f #.
- Помещено в коробку, когда в этом нет необходимости, возможно, из-за того, что не используется ограниченный код операции
- Я никогда не видел, чтобы это происходило, но Мне нравится пример, где это происходит.
В настоящее время компиляторы C # и vb.net оставляют такие сложности оптимизации, как регистрация переменных, соглашения о вызовах, встраивание и развертывание полностью до общего JIT-компилятора в CLR. Это, вероятно, окажет гораздо большее влияние на что-либо еще (особенно когда 32-битные и 64-битные JIT теперь могут вести себя совершенно по-разному).
Это зависит от того, что вы делаете. Я думаю, что нет реальной разницы между VB и C #. Оба они являются языками .Net и скомпилированы на IL.
Подробнее? Прочтите это:
В сгенерированном коде есть небольшие отличия, которые в некоторых ситуациях могут сделать C # немного быстрее. Например, в VB.NET есть дополнительный код для очистки локальных переменных в методе, в то время как в C # нет.
Однако эти различия едва ли поддаются измерению, и большая часть кода настолько далека от оптимального, что вы просто начинаете неправильно закончите переключением языка, чтобы код работал быстрее. Вы можете взять практически любой код, интенсивно использующий процессор, и довольно легко сделать его вдвое быстрее. Один код можно сделать в 10 раз быстрее, другой - в 10000 раз. В этом контексте те несколько процентов, которые вы можете получить, используя C # вместо VB.NET, не стоят затраченных усилий
. С другой стороны, изучение C # вполне может быть эффективным способом ускорения вашего кода. Не потому, что C # может производить более быстрый код, Очевидно, что компиляторы C # и VB.NET разработаны более или менее синхронно. Разница в скорости между C # 1 и C # 2 составляет примерно 30%, разница между параллельными версиями C # и VB.NET намного меньше.