Повышение производительности при переписывании кода C # на C / C ++

Один из вариантов - переписать код C как небезопасный C #, который должен иметь примерно одинаковую производительность и не влечет за собой никаких штрафов за взаимодействие.

Здесь уже есть несколько довольно хороших ответов, особенно @Steve Townsend.

Тем не менее, мне показалось, что стоит подчеркнуть ключевой момент: По сути, нет никаких причин, по которым код C «будет быстрее», чем код C # . Эта идея миф. Под капотом они оба выдают машинный код, который работает на одном и том же процессоре. До тех пор, пока вы не попросите C # выполнить больше работы , чем C, тогда он может выполнять то же самое.

Переключившись на C, вы заставили себя быть более скромным (вы избежали использования высокоуровневых функций, таких как управляемые строки, проверка границ, сборка мусора, обработка исключений и т. Д., И просто рассматривали ваши строки как блоки необработанных байтов). Если бы вы применили эти низкоуровневые методы к своему коду C # (то есть обработали ваши данные как необработанные блоки байтов, как вы это делали в C), вы бы обнаружили гораздо меньшую разницу в скорости.

Например: на прошлой неделе я переписал (на C #) класс, который написал младший (также на C #). Я достиг 25-кратного улучшения скорости по сравнению с исходным кодом, применив тот же подход, который использовал бы , если бы я писал его на C (то есть , думая о производительности). Я добился того же ускорения, на которое вы претендуете, даже не переходя на другой язык.

Наконец, то, что отдельный случай может быть сделан в 24 раза быстрее, это не означает, что вы можете сделать всю программу в 24 раза быстрее по всем направлениям, перенеся все это на C. Как сказал Стив, профилируйте его, чтобы работать там, где он медленный и тратить свои усилия только там, где это принесет значительные выгоды. Если вы слепо конвертируете в C, вы, вероятно, обнаружите, что потратили много времени на то, чтобы сделать уже работающий код менее понятным.

(PS Моя точка зрения основана на 29-летнем опыте написания кода на ассемблере, C, C ++ и C # и понимания того, что язык - это всего лишь инструмент для генерации машинного кода - в случае C # против C ++ и C это в первую очередь навыки программиста, а не используемый язык, который определяет, будет ли код выполняться быстро или медленно. Программисты на C / C ++, как правило, лучше программистов на C #, потому что они должны быть - C # позволяет вам быть ленивым и быстро писать код в то время как C / C ++ заставляет вас выполнять больше работы, а написание кода занимает больше времени, но хороший программист может добиться высокой производительности на C #, а плохой программист может вырвать ужасную производительность на C / C ++)

Нет смысла писать на C поверх C ++, а C / C ++ не существует.

Показатели эффективности маршаллинга довольно просты. Если вам придется маршалировать каждую струну индивидуально, то ваша производительность будет отстойной. Если вы можете собрать все десять миллионов строк за один вызов, то сортировка не будет иметь никакого значения вообще. P / Invoke - не самая быстрая операция в мире, но если вы вызываете ее только несколько раз, это не имеет большого значения.

Может быть проще переписать ваше основное приложение на C ++, а затем использовать C ++ / CLI для объединения его с концом базы данных C #.

Поскольку строки являются неизменяемыми в .NET, я не сомневаюсь, что оптимизированная реализация C превзойдет оптимизированную реализацию C # - , без сомнения!

В P / Invoke возникают накладные расходы, но если вы реализуете большую часть логики в C и предоставляете только очень гранулированный API для C #, я думаю, вы в гораздо лучшей форме.

В конце концов, написание реализации на C означает больше времени, но это даст вам лучшую производительность, если вы подготовитесь к дополнительным затратам на разработку.

Ознакомьтесь со смешанными сборками - это лучше, чем Interop. Interop - это быстрый способ справиться с нативными библиотеками, но смешанные сборки работают лучше.
Смешанные сборки на MSDN
Как обычно, главное - это тестирование и измерение ...

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

Если это не достаточно быстро для вас, вы можете использовать char- или byte-массивы вместо строк и работать с ними. Если вы закончили с манипуляциями, вы можете преобразовать массив обратно в строку.

В C # также есть возможность использовать небезопасный код , чтобы получить указатель на строку и изменить неизменяемую строку, но я бы не стал этого рекомендовать.

Как уже говорили другие, вы можете использовать управляемый C ++ (C ++ / CLI) для приятного взаимодействия между .NET и управляемым кодом.

Не могли бы вы показать нам код, может быть, есть другие варианты оптимизации?

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

Профилирование - это первый шаг, чтобы увидеть, куда идут все эти циклы ЦП.

Просто имейте в виду, что профилировщики C # будут только профилировать ваше приложение .Net, а не сервер IIS, реализованный в ядре, и сетевой стек.

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

Там вы думаете, что не имеете никакого влияния на IIS, реализованный как драйвер ядра - и вы правы.

Но вы можете обойтись без него - и сэкономить много времени и денег.

Поместите свой талант туда, где это может иметь значение, а не туда, где вы вынуждены бежать со связанными ногами.

Присущие различия, как правило, приведены в 2 раза меньше ресурсов процессора, в 5 раз меньше памяти. На практике лишь немногие люди достаточно хороши в C ++ и получают преимущества.

Существует дополнительная выгода для экономии на поддержке Unicode, но только вы можете знать свое приложение достаточно хорошо, чтобы знать, безопасно ли это.

Сначала используйте профилировщик, убедитесь, что вы не привязаны к вводу / выводу.