Производительность C++/CLI по сравнению с Native C++?

Доброе утро,

Я пишу средство проверки орфографии, которое в данном случае критично для производительности. При этом, и поскольку я планирую подключиться к БД и создать графический интерфейс с помощью C #, я написал процедуру расчета расстояния редактирования на C и скомпилировал ее в DLL, которую я использую в C #, используя DllImport. Проблема в том, что я думаю (хотя, возможно, я ошибаюсь), что упорядочивание слов одно за другим от String до char * вызывает много накладных расходов. При этом я подумал об использовании C++/CLI, чтобы я мог напрямую работать с типом String в .NET... Мой вопрос в том, как производительность C++/CLI сравнивается с собственным кодом C для тяжелых математических вычислений и доступа к массиву?

Большое Вам спасибо.


person Miguel    schedule 06.12.2010    source источник
comment
Я думаю, CIL делает то же самое, но неявно.   -  person Saeed Amiri    schedule 06.12.2010
comment
Почему вы передаете слова одно за другим? Передать весь txt.   -  person Lukasz Madon    schedule 06.12.2010


Ответы (3)


C++/CLI также должен будет выполнить некоторую маршалинг.

Как и все проблемы, связанные с производительностью, вы должны измерять и оптимизировать. Вы уверены, что C# недостаточно быстр для ваших целей? Не стоит недооценивать оптимизацию, которую собирается выполнить JIT-компилятор. Не спекулируйте на накладных расходах языковой реализации исключительно из-за того, что ими можно управлять без усилий. Если этого недостаточно, рассмотрели ли вы небезопасный код C# (с указателями), прежде чем пытаться использовать неуправляемый код?

Что касается профиля производительности C++/CLI, то он действительно зависит от того, как он используется. Если вы скомпилируете управляемый код (CIL) с помощью (/clr:pure), он не будет сильно отличаться от C#. Собственные функции C++ в C++/CLI будут иметь такие же характеристики производительности, как и обычный C++. Передача объектов между собственной средой C++ и средой CLI будет иметь некоторые накладные расходы.

person mmx    schedule 06.12.2010
comment
Небезопасный код C# примерно в два раза медленнее, чем функция C, которую я импортирую с помощью DllImport. - person Miguel; 06.12.2010

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

person weismat    schedule 06.12.2010

Не думайте, что вы знаете, что нужно оптимизировать. Пусть выборка скажет вам.

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

person Mike Dunlavey    schedule 06.12.2010
comment
Это не так... На самом деле я использую BK-Tree, поэтому мой подход значительно отличается от того, что вы сказали. - person Miguel; 06.12.2010
comment
@Miguel: Хорошо, исправлено. В любом случае, то, что я сделал, было поиском по ветвям и границам в дереве, который работал довольно хорошо. Альтернативой является смешанный метод "сначала в глубину" и "сначала вширь", но я думал, что метод "ветвь и граница" имеет примерно такую ​​же производительность и гораздо более гибкий с точки зрения типов орфографических ошибок, которые он может обрабатывать. - person Mike Dunlavey; 06.12.2010