Действительно ли C# медленнее, чем c++?
Мне было интересно об этой проблеме в течение некоторого времени.
конечно, в C# есть вещи, которые не оптимизированы для скорости, поэтому использование этих объектов или языковых настроек (например, LinQ) может привести к замедлению кода.
но если вы не используете ни одну из этих настроек, а просто сравниваете одни и те же фрагменты кода в C# и C++ (их легко перевести друг на друга). Это действительно будет намного медленнее ?
Я видел сравнения, которые показывают, что C# может быть даже быстрее в некоторых случаях, потому что теоретически JIT-компилятор должен оптимизировать код в реальном времени и получить лучшие результаты:
Управляемый Или Неуправляемый?
мы должны помнить, что JIT-компилятор компилирует код в режиме реального времени, но это 1-кратные накладные расходы, тот же код (после достижения и компиляции) не нужно компилировать снова во время выполнения.
GC также не добавляет много накладных расходов, если вы не создадите и не уничтожите тысячи объекты (например, используя строку вместо StringBuilder). И делать это в C++ также было бы дорого.
еще один момент, который я хочу поднять, - это лучшая связь между DLL, введенными в .Net. платформа .Net взаимодействует намного лучше, чем управляемые библиотеки DLL на основе COM.
Я не вижу никакой внутренней причины, почему язык должен быть медленнее, и я действительно не думаю, что C# медленнее, чем C++ (как из опыта, так и из-за отсутствия хорошего объяснение.).
итак, будет ли кусок одного и того же кода, написанного на C#, медленнее, чем тот же код в C++ ?
Если да, то почему ?
некоторые другие ссылки (которые говорят об этом немного, но без объяснения причин):
почему вы хотите использовать C#, если его медленнее, чем C++?
12 ответов:
предупреждение: вопрос, который вы задали, действительно довольно сложный-вероятно, гораздо больше, чем вы понимаете. В результате, это действительно длинный ответ.
с чисто теоретической точки зрения, вероятно, есть простой ответ на это: в C# нет (вероятно) ничего, что действительно мешает ему быть таким же быстрым, как C++. Несмотря на теорию, однако, есть некоторые практические причины, что это и медленнее в некоторых вещах под некоторыми обстоятельства.
Я рассмотрю три основных различия: язык, выполнение виртуальной машины, и сбор мусора. Последние два часто идут вместе, но могут быть независимыми, поэтому я буду смотреть на них по отдельности.
Языковые Особенности
C++ уделяет большое внимание шаблонам и функциям в системе шаблонов, которые в основном предназначены для того, чтобы как можно больше сделать во время компиляции, поэтому с точки зрения программа, они " статичны."Шаблонное метапрограммирование позволяет выполнять полностью произвольные вычисления во время компиляции (т. е. система шаблонов является полной по Тьюрингу). Таким образом, практически все, что не зависит от ввода от пользователя, может быть вычислено во время компиляции, поэтому во время выполнения это просто константа. Однако вход в это может включать такие вещи, как информация о типе, поэтому многое из того, что вы делаете через отражение во время выполнения в C#, обычно выполняется во время компиляции с помощью шаблона метапрограммирование в C++. Существует определенно компромисс между скоростью выполнения и универсальностью, хотя-что шаблоны могут делать, они делают статически, но они просто не могут делать все, что может отражение.
различия в особенностях языка означают, что почти любая попытка сравнения двух языков просто путем транслитерации некоторого C# в C++ (или наоборот), вероятно, приведет к результатам где-то между бессмысленным и вводящим в заблуждение (и то же самое будет верно для большинства других пар языки также). Простой факт заключается в том, что для чего-либо большего, чем пара строк кода или около того, почти никто не может использовать языки одинаково (или достаточно близко к тому же), что такое сравнение говорит вам о том, как эти языки работают в реальной жизни.
Виртуальная Машина
Как и почти любая разумно современная виртуальная машина, Microsoft для .NET может и будет делать JIT (он же "динамическая") компиляция. Однако это представляет собой ряд компромиссов.
в первую очередь, оптимизации кода (как и большинство других задач оптимизации) в значительной степени является NP-полной задачей. Для чего угодно, кроме действительно тривиальной / игрушечной программы, вы почти уверены, что вы действительно не "оптимизируете" результат (т. е. вы не найдете истинного оптимума) - оптимизатор просто сделает код лучше чем это было ранее. Однако для выполнения довольно многих хорошо известных оптимизаций требуется значительное количество времени (и, часто, памяти). С JIT-компилятор, пользователь ждет, пока компилятор работает. Большинство более дорогих методов оптимизации исключены. Статическая компиляция имеет два преимущества: Во-первых, если она медленная (например, построение большой системы), она обычно выполняется на сервере и никто тратит время на его ожидание. Во-вторых, исполняемый файл может быть сгенерирован после, и используется много раз многими людьми. Первый сводит к минимуму затраты на оптимизацию; второй амортизирует гораздо меньше стоимость за гораздо большее количество казней.
Как уже упоминалось в исходном вопросе (и на многих других веб-сайтах), JIT-компиляция действительно имеет возможность большей осведомленности о целевой среде, что должно (по крайней мере теоретически) компенсировать это преимущество. Нет никаких сомнений в том, что этот фактор может компенсировать по крайней мере часть недостатка статической компиляции. Для нескольких довольно специфических типов кода и целевых сред это can даже перевешивают преимущества статической компиляции, иногда довольно резко. По крайней мере, в моем тестировании и опыте, однако, это довольно необычно. Целевые зависимые оптимизации в основном, по-видимому, либо имеют довольно небольшие различия, либо могут быть применены (автоматически, во всяком случае) к довольно конкретным типам проблем. Очевидно, что это произошло бы, если бы вы запускали относительно старую программу на современной машине. Старая программа, написанная на C++, вероятно, была бы скомпилирована в 32-разрядный код, и будет продолжать использовать 32-разрядный код даже на современном 64-разрядном процессоре. Программа, написанная на C#, была бы скомпилирована в байтовый код, который виртуальная машина затем скомпилировала бы в 64-разрядный машинный код. Если эта программа получила существенную выгоду от работы в качестве 64-разрядного кода, это может дать существенное преимущество. За короткое время, когда 64-битные процессоры были довольно новыми, это произошло довольно много. Последний код, который, вероятно, выиграет от 64-разрядного процессора, обычно будет доступен скомпилированным статически в 64-разрядный код.
использование виртуальной машины также имеет возможность улучшить использование кэша. Инструкции для виртуальной машины часто более компактны, чем собственные машинные инструкции. Больше из них может поместиться в заданный объем кэш-памяти, так что вы стоите больше шансов любой данный код находится в кэше, когда это необходимо. Это может помочь сохранить интерпретируемое выполнение кода виртуальной машины более конкурентоспособным (с точки зрения скорости), чем большинство людей изначально ожидали-вы можете выполнить много of инструкции по современному процессору за время, потраченное один кэша.
также стоит отметить, что этот фактор не обязательно отличается между ними вообще. Ничто не мешает (например) компилятору C++ создавать выходные данные, предназначенные для работы на виртуальной машине (с JIT или без него). На самом деле, Microsoft C++/CLI-это почти это -- (почти) соответствующий компилятор C++ (хотя и с большим количеством расширений), который производит вывод предназначен для работы на виртуальной машине.
обратное также верно: Microsoft теперь имеет .NET Native, который компилирует C# (или VB.NET) код для собственного исполняемого файла. Это дает производительность, которая обычно намного больше похожа на C++, но сохраняет функции C#/VB (например, c#, скомпилированный в машинный код, по-прежнему поддерживает отражение). Если у вас есть высокопроизводительный код C#, это может быть полезно.
Вывоз Мусора
из того что я видел, я бы сказал, что фигня сбор является самым бедным из этих трех факторов. Просто для очевидного примера здесь упоминается вопрос: "GC также не добавляет много накладных расходов, если вы не создаете и не уничтожаете тысячи объектов [...]". На самом деле, если вы создаете и уничтожить тысячи объектов, накладные расходы от сбора мусора, как правило, будет довольно низким. .NET использует поколенческий мусорщик, который является разновидностью копирующего коллектора. Сборщик мусора работает, начиная с "места" (например, регистры и стек выполнения), что указатели / ссылки известный быть доступным. Затем он "преследует" те указатели на объекты, которые были выделены в куче. Он исследует эти объекты для дальнейших указателей / ссылок, пока не проследит за всеми из них до концов любых цепочек и не найдет все объекты, которые (по крайней мере, потенциально) доступны. На следующем шаге он принимает все объекты, которые есть (или, по крайней мере,может быть) в пользе, и компактирует куча путем копирования всех из них в непрерывный кусок на одном конце памяти, управляемой в куче. Остальная часть памяти тогда свободна (нужно запускать финализаторы по модулю, но, по крайней мере, в хорошо написанном коде, они достаточно редки, чтобы я их игнорировал на данный момент).
что это означает, что если вы создаете и уничтожить множество объектов, сбор мусора добавляет очень мало накладных расходов. Время, затрачиваемое циклом сборки мусора, почти полностью зависит от количество объектов, которые были созданы, но не уничтожены. Основным следствием создания и уничтожения объектов в спешке является просто то, что GC должен работать чаще, но каждый цикл все равно будет быстрым. Если вы создаете объекты и не уничтожить их, GC будет работать чаще и каждый цикл будет существенно медленнее, поскольку он тратит больше времени на преследование указателей на потенциально живые объекты,и он тратит больше времени на копирование объекты, которые все еще используются.
чтобы бороться с этим, поколенческая очистка работает в предположении, что объекты, которые есть оставались "живыми" в течение довольно долгого времени, вероятно, продолжат оставаться живыми в течение довольно долгого времени. Исходя из этого, у него есть система, в которой объекты, которые переживают некоторое количество циклов сбора мусора, становятся "арендованными", и сборщик мусора начинает просто предполагать, что они все еще используются, поэтому вместо того, чтобы копировать их в каждом цикле, он просто уходит они одни. Это справедливое предположение достаточно часто, что генерационная очистка обычно имеет значительно более низкие накладные расходы, чем большинство других форм GC.
"ручное" управление памятью часто так же плохо понимается. Только для одного примера многие попытки сравнения предполагают, что все ручное управление памятью также следует одной конкретной модели (например, наилучшее распределение). Это часто немного (если таковые имеются) ближе к реальности, чем убеждения многих народов о сборе мусора (например, широко распространенное предположение, что это обычно делается с помощью подсчета ссылок).
учитывая разнообразие стратегий как для сбора мусора и ручное управление памятью, это довольно трудно сравнить два с точки зрения общей скорости. Попытка сравнить скорость выделения и / или освобождения памяти (сама по себе) почти гарантированно приведет к результатам, которые в лучшем случае бессмысленны, а в худшем-просто вводят в заблуждение.
Бонусные Темы: Контрольные показатели
, Так как довольно много блогов, веб-сайтов, журнальных статей и т. д. утверждая, что я предоставляю "объективные" доказательства в том или ином направлении, я также вложу свои два цента в эту тему.
большинство из этих критериев немного похожи на подростков, решающих участвовать в гонках на своих автомобилях, и тот, кто выигрывает, получает оба автомобиля. Однако веб-сайты отличаются одним важным способом: они парень, который публикует бенчмарк, получает возможность управлять обоими автомобилями. По какой-то странной случайности, его автомобиль всегда выигрывает, и все остальные должны довольствоваться "поверь мне, я был действительно вождение автомобиля так быстро, как это будет идти."
легко написать плохой тест, который дает результаты, которые почти ничего не значат. Почти любой человек, обладающий навыками, необходимыми для разработки эталона, который производит что-либо значимое, также имеет навык создавать тот, который даст результаты, которые он решил, что хочет. На самом деле это, вероятно,легче написать код для создайте конкретный результат, чем код, который действительно даст значимые результаты.
вывод
нет простого ответа. Я достаточно уверен, что могу перевернуть монету, чтобы выбрать победителя, а затем выбрать число между (скажем) 1 и 20 для процента, на который он выиграет, и написать некоторый код, который будет выглядеть разумным и справедливым эталоном, и произвел это предрешено (по крайней мере, на каком-то целевом процессоре-другой процессор может немного изменить процент).
как указывали другие, для большинство код, скорость почти не имеет значения. Следствием этого (что гораздо чаще игнорируется) является то, что в небольшом коде, где скорость имеет значение, обычно имеет значение много. По крайней мере, по моему опыту, для кода, где это действительно имеет значение, C++ почти всегда является победителем. Есть определенно факторы, которые благоприятствуют C#, но на практике они, похоже, перевешиваются факторами, которые благоприятствуют C++. Вы, конечно, можете найти тесты, которые будут указывать на результат вашего выбора, но когда вы пишете реальный код, вы почти всегда можете сделать это быстрее в C++, чем в C#. Это может (или не может) занять больше навыков и/или усилий, чтобы написать, но это практически всегда возможно.
потому что вам не всегда нужно использовать (и я использую это свободно) "самый быстрый" язык? Я не езжу на работу в Ferrari только потому, что это быстрее...
C++ всегда имеют преимущество для производительности. С C# я не могу обрабатывать память, и у меня есть буквально тонны ресурсов, доступных для меня, чтобы делать свою работу.
то, что вам нужно, чтобы спросить себя больше о том, какой из них экономит ваше время. Машины сейчас невероятно мощная и большая часть кода должна быть выполнена на языке, который позволяет получить максимум пользы в минимум времени.
Если есть основная обработка, которая занимает слишком много времени в C#, вы можете затем создайте C++ и взаимодействуйте с ним с помощью C#.
перестаньте думать о производительности кода. Начните строить значение.
около 2005 года два эксперта по производительности MS с обеих сторон родного / управляемого забора попытались ответить на один и тот же вопрос. Их метод и процесс все еще увлекательны, и выводы все еще держатся сегодня - и я не знаю лучшей попытки дать информированный ответ. Они отметили, что обсуждение возможные причины ибо различия в производительности гипотетичны и бесполезны, и истинное обсуждение должно иметь некоторые эмпирическая основа для реального мира влияние таких различий.
Итак,Старый Новый Раймонд Чен и Рико Мариани установить правила для дружеского соревнования. В качестве контекста приложения для игрушек был выбран китайский / английский словарь: достаточно простой, чтобы быть закодированным как побочный проект хобби, но достаточно сложный, чтобы продемонстрировать нетривиальные шаблоны использования данных. Правила начинались просто-Раймонд закодировал простую реализацию C++, Рико перенес ее на C# строка за строкой, без изощренность какая бы то ни было, и обе реализации запускали эталон. Затем последовало несколько итераций оптимизации.
полная информация здесь:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15, 16.
этот диалог титанов исключительно познавательный и я всем сердцем рекомендую погрузиться-но если вам не хватает времени или терпения, Джефф Этвуд собрал нижние строки красиво:
в конце концов, C++ был в 2 раза быстрее - но первоначально он был в 13 раз медленнее.
Как Рико подытоживает:
Так мне стыдно за мое сокрушение поражение? Едва. Управляемый код добился очень хорошего результата практически без каких-либо усилий. Чтобы победить управляемая версия, Раймонд должен был:
написать свой собственный файл / io вещи
написать свой собственный класс строки
написать свой аллокатор
написать свою собственную международную карту
конечно, он использовал доступные библиотеки нижнего уровня, чтобы сделать этот, но это еще много работы. Можете ли вы назвать то, что осталось STL программа? Я так не думаю.
Это мой опыт до сих пор, 11 лет и кто знает, сколько версий C#/C++ позже.
Это не случайно, конечно, поскольку эти два языка эффектно достигают своих совершенно разных целей дизайна. C# хочет использоваться там, где стоимость разработки является основным соображением (по-прежнему большинство программного обеспечения), а C++ сияет там, где вы не сэкономите никаких расходов выжмите из своей машины все до последней унции производительности: игры, алго-трейдинг, дата-центры и т. д.
C# и быстрее, чем C++. Быстрее писать. Для времени выполнения, ничто не сравнится с профайлером.
но C# не имеет столько библиотек,сколько C++ может легко взаимодействовать.
и C# сильно зависит от windows...
кстати, критические по времени приложения не кодируются в C# или Java, в первую очередь из-за неопределенности того, когда будет выполняться сборка мусора.
в наше время скорость приложения или выполнения не так важна, как раньше. Графики развития, правильность и надежность являются более высокими приоритетами. Высокоскоростная версия приложения не годится, если в ней много ошибок, много сбоев или хуже, отсутствует возможность выйти на рынок или быть развернутым.
поскольку графики разработки являются приоритетными, появляются новые языки, которые ускоряют разработку. C# является одним из них. C# также помогает в правильности и надежности, удаляя функции из C++, которые вызывают общие проблемы: одним из примеров являются указатели.
различия в скорости выполнения приложения, разработанного на C# и разработанного с использованием C++, незначительны на большинстве платформ. Это связано с тем, что узкие места выполнения не являются языковыми зависит, но обычно зависит от операционной системы или ввода-вывода.например, если C++ выполняет функцию за 5 мс, но C# использует 2 мс, а ожидание данных занимает 2 секунды, время, затраченное на функцию, незначительно по сравнению с временем ожидания данных.
выбрать язык, который лучше всего подходит для разработчиков, платформы и проекты. Работа в направлении достижения целей корректности, надежности и развертывания. Скорость работы приложения следует рассматривать как ошибку: расставить приоритеты, сравнить к другим ошибкам, и исправить по мере необходимости.
лучший способ взглянуть на это все медленнее, чем C/C++, потому что он абстрагируется, а не следует парадигме палки и грязи. Это называется системным программированием по какой-то причине, вы программируете против зерна или голого металла. Это также дает вам скорость, которую вы не можете достичь с другими языками, такими как C# или Java. Но, увы, корни C-это все о том, чтобы делать вещи трудным путем, поэтому вы в основном будете писать больше кода и тратить больше времени на его отладку.
C также имеет место чувствительные, также объекты в C++ также следуют строгим наборам правил. Например, фиолетовый конус мороженого может не совпадать с синим конусом мороженого, хотя они могут быть конусами, они не обязательно могут принадлежать к семейству конусов, и если вы забыли определить, какой конус вы ошибаетесь. Таким образом, свойства мороженого могут быть или не быть клонами. Теперь аргумент скорости, C / C++ использует подход к стеку и куче, где голый металл получает его металл.
с помощью библиотеки boost вы можете достичь невероятные скорости к сожалению большинство игровых студий придерживаются стандартной библиотеки. Другая причина этого может заключаться в том, что программное обеспечение, написанное на C/C++, имеет тенденцию быть массивным по размеру файла, поскольку это гигантская коллекция файлов вместо одного файла. Также обратите внимание, что все операционные системы написаны на C так обычно, почему мы должны задать вопрос, что может быть быстрее?!
также кэширование не быстрее, чем управление чистой памятью, извините, но это просто не разветвляется. Память-это нечто физическое, кэширование-это то, что делает программное обеспечение, чтобы получить удар по производительности. Можно также предположить, что без кэширования физической памяти просто не существовало бы. Это не аннулирует тот факт, что память должна управляться на каком-то уровне, будь то автоматизированная или ручная.
Почему вы пишете небольшое приложение, которое не требует многого на пути оптимизации в C++, если есть более быстрый маршрут(C#)?
получить точный ответ на ваш вопрос на самом деле невозможно, если вы не выполняете тесты на конкретных системах. Тем не менее, по-прежнему интересно подумать о некоторых фундаментальных различиях между языками программирования, такими как C# и C++.
сборник
выполнение кода C# требует дополнительного шага, на котором код JIT'Ed. Что касается производительности, то это будет в пользу C++. Кроме того, JIT-компилятор может оптимизировать сгенерированный код внутри единицы кода JIT'Ed (например, метод), в то время как компилятор C++ может оптимизировать вызовы методов с использованием более агрессивных методов.
тем не менее, JIT-компилятор способен оптимизировать сгенерированный машинный код, чтобы он точно соответствовал базовому оборудованию, что позволяет ему использовать дополнительные аппаратные функции, если они существуют. Насколько мне известно, компилятор .NET JIT этого не делает, но он, по-видимому, сможет генерировать другой код для Atom как в отличие от процессора Pentium.
доступ к памяти
собранная архитектура мусора может во многих случаях создавать более оптимальные шаблоны доступа к памяти, чем стандартный код C++. Если область памяти, используемая для первого поколения, достаточно мала, она может оставаться в кэше ЦП, увеличивая производительность. Если вы создаете и уничтожаете много небольших объектов, накладные расходы на обслуживание управляемой кучи могут быть меньше, чем требуется средой выполнения C++. Опять же, это сильно зависит от применения. исследование Python производительности демонстрирует, что конкретное управляемое приложение Python может масштабироваться намного лучше, чем скомпилированная версия, в результате более оптимальных шаблонов доступа к памяти.
основной проблемой будет не скорость, а стабильность в версиях и обновлениях windows. Win32 в основном обладает иммунитетом к версиям windows, что делает его очень стабильным.
когда серверы выведены из эксплуатации и программное обеспечение перенесено, много беспокойства происходит вокруг всего, что использует .Net и обычно много паники о версиях .net, но приложение Win32, построенное 10 лет назад, просто продолжает работать, как ничего не произошло.
Не позволяйте смущать!
Если приложение C# написано в лучшем случае, а приложение C++ написано в лучшем случае, C++ быстрее.
Многие причины здесь о том, почему C++ быстрее, что C# по своей сути, например C# использует виртуальную машину, подобную JVM в Java. В основном язык более высокого уровня имеет меньшую производительность (если используется в лучшем случае).Если вы опытный профессиональный программист C# так же, как вы опытный профессиональный программист на C++, Разработка приложения с использованием C# намного проще и быстрее, чем на C++.
многие другие ситуации между этими ситуациями возможны. Например, вы можете писать приложения на C# и C++ приложения, так что приложение c# работает быстрее, чем на C++.
при выборе языка следует учитывать обстоятельства проекта и его тематику. Для общего бизнес-проекта следует использовать C#. Для высокой производительности необходимый проект, такой как видео конвертер или проект обработки изображений, вы должны выбрать C++.
обновление:
ОК. Давайте сравним некоторые практические причины о том, почему наиболее возможная скорость C++ больше, чем C#. Рассмотрим хорошее письменное приложение C# и ту же версию C++:
- C# использует виртуальную машину в качестве среднего слоя для выполнения приложения. У него есть накладные расходы.
- AFAIK CLR не может оптимизировать все коды C# в целевой машине. Приложение на C++ может быть скомпилирован на целевой машине с большей оптимизацией.
- В C# наиболее возможная оптимизация для времени выполнения означает наиболее возможную быструю виртуальную машину. VM имеет накладные расходы в любом случае.
- C# - это язык более высокого уровня, поэтому он генерирует больше строк программного кода для окончательного процесса. (рассмотрим разницу между приложением сборки и Ruby one! то же самое условие находится между C++ и языком более высокого уровня, таким как C#/Java)
Если вы хотите получить больше информации на практике как эксперт,посмотреть этот. Речь идет о Java, но это также относится и к C#.
Я специализируюсь на оптимизации около 15 лет и регулярно переписываю код C++, максимально используя встроенные компиляторы, потому что производительность C++ часто не приближается к тому, на что способен процессор. Производительность кэша часто необходимо учитывать. Многие инструкции по векторной математике требуются для замены стандартного кода C++ с плавающей запятой. Много кода STL переписывается и часто работает во много раз быстрее. Математика и код, который делает интенсивное использование данных можно переписать с впечатляющими результатами, так как процессор приближается к своей оптимальной производительности.
ничего из этого невозможно в C#. Сравнить их относительную производительность #в реальном времени# - это действительно ошеломляюще невежественный вопрос. Самый быстрый фрагмент кода в C++ будет, когда каждая отдельная инструкция ассемблера будет оптимизирована для поставленной задачи, без лишних инструкций - вообще. Где каждый кусок памяти используется, когда это требуется, а не копируется n раз, потому что это то, что языковой дизайн требует. Где каждое требуемое движение памяти работает в гармонии с кэшем. Где окончательный алгоритм не может быть улучшен, основанный на точных требованиях реального времени, учитывая точность и функциональность.
затем вы будете приближаться к оптимальному решению.
сравнивать C# с этой идеальной ситуацией просто потрясающе. C# не может конкурировать. На самом деле, в настоящее время я пишу целую кучу кода C# (когда я говорю re writing, я имею в виду удаление и замену его полностью) потому что это даже не в том же городе, не говоря уже о парке мяч, когда дело доходит до тяжелой работы в режиме реального времени.
Так что, пожалуйста, перестаньте обманывать себя. C# - это медленно. Очень медленно. Все программное обеспечение замедляется, и C# делает это снижение скорости хуже. Все программное обеспечение работает с использованием цикла выполнения выборки в ассемблере (вы знаете – на процессоре). Вы используете в 10 раз больше инструкций; это будет идти в 10 раз медленнее. Вы калечите кэш; он будет идти еще медленнее. Добавить сбор мусора в реальном времени часть программного обеспечения, то вы часто обманывают, думая, что код работает " ОК "Есть только те несколько моментов, каждый сейчас и потом, когда код идет "немного медленно на некоторое время".
попробуйте добавить систему сбора мусора в код, где каждый цикл считается. Интересно, есть ли у программного обеспечения для торговли на фондовом рынке сбор мусора (вы знаете – на системе, работающей на новом подводном кабеле, который стоит 300 миллионов долларов?). Можем ли мы сэкономить 300 миллисекунд каждые 2 секунды? Как насчет программного обеспечения управления полетом на космическом челноке-GC в порядке? Как о програмном обеспечении управления двигателя в кораблях представления? (Где победа в сезоне может стоить миллионы).
сбор мусора в режиме реального времени является полным провалом.
Так что нет, решительно, C++ намного быстрее. C# - это прыжок назад.