Собственная производительность C ++ с использованием C # или в C # - PullRequest
2 голосов
/ 27 мая 2011

Мне было интересно, имеют ли два следующих сценария одинаковое влияние на производительность для собственного кода C ++ (если вообще есть какое-либо влияние на производительность).

Предположим, у меня есть функция cpp_calc(), которая выполняет некоторые вычисления и написана на нативном C ++. Также есть cs_show_gui_stuff(), который написан на C #.

Теперь, какой из следующих сценариев ухудшит собственную производительность c ++ (если вообще есть какое-либо снижение производительности)?

  1. Создание приложения .Net (C #) , которое запускает cs_show_gui_stuff() и вызывает cpp_calc() в собственной C ++ dll, используя DllImport или превращая C ++ в COM DLL.

  2. Создание приложения C ++ , которое реализует cpp_calc() в C ++ и запускает cs_show_guid_stuff() путем помещения кода C # в .Net COM DLL.

Спасибо: -)

Ответы [ 2 ]

9 голосов
/ 27 мая 2011

Это действительно зависит от того, во что в основном написаны другие части системы. С точки зрения производительности только один вызов PInvoke (через атрибут DllImport), вероятно, будет быстрее, чем один вызов COM, если аргументы методане нужно никакого особого маршалинга.

Третья, и, возможно, лучшая альтернатива, - это создание управляемой библиотеки C ++ / CLI, которая вызывает неуправляемый метод C ++ практически без влияния на производительность, и добавление ссылки на библиотеку C ++ / CLI в приложении C #.Затем приложение C # может выполнять вызовы управляемых методов к приложению C ++ / CLI, которые, в свою очередь, могут выполнять неуправляемые вызовы методов.Хотя это добавляет один уровень косвенности, оно обеспечит гораздо лучшую производительность, чем методы, которые вы упоминали.

1 голос
/ 27 мая 2011

В любом случае Вы столкнетесь с компилятором Just-In-Time.Я думаю, штраф в обоих сценариях одинаков.Я бы лично выбрал первый, потому что .NET-библиотеки более устойчивы в графическом интерфейсе - WPF, Silverlight, WinForms, WebForms, Razor ... Вы понимаете, о чем я.

...