Родной c ++ dll работает медленнее, когда вызывается из VB.net, по сравнению с работающим, вызываемым из родного .exe

Question

У меня есть некоторый код на нативном C ++ (Visual C ++ 2010) для обработки файла размером в несколько ГБ. Я скомпилировал его в .exe, и это занимает около 8 минут. Но мне нужно вызвать его из интерфейса Visual Basic .net, поэтому я поместил его в .dll и создал класс-оболочку c ++ / cli для вызова моего кода в нативной DLL. Единственное взаимодействие между управляемым кодом и собственной dll - это вызов функции, которая инициирует обработку. К моему удивлению, обработка занимает почти вдвое больше времени, чем путь .exe. Я на самом деле не эксперт в VB.net, поэтому, может быть, есть какие-то настройки или что-то, на что я смотрю, я не знаю. Любая идея приветствуется. Заранее спасибо.

Answer 1

Пара идей:

• Возможно, вы создали .exe с использованием конфигурации выпуска, но для DLL был установлен параметр Отладка.Иногда вы видите большую разницу между сборками выпуска и отладки, оптимизированный код имеет огромное значение.

• Если ваш VB.net делает что-то кроме вызова кода C ++, то это может добавить нагрузку на процессорповерх того, что потребляет ваш .dll.Любая фоновая обработка, выполняемая на стороне VB.net, может объяснить разницу.Для сравнения яблок с яблоками у вас должно быть приложение для командной строки VB.net без графического интерфейса и с одной строкой, которая вызывает функцию dll.

• Если приведенное выше не помогает, яРекомендуем создать собственное приложение C ++, которое связывается с этой же DLL, и сравнить его с собственной версией exe.Если версия C ++ и DLL работает так же, как и отдельная exe-версия C ++, то на стороне VB.net должно быть что-то, потребляющее дополнительный процессор.Если, с другой стороны, DLL также медленно работает при вызове из собственного C ++, вам следует искать различия в процессе сборки для exe и dll или различия в макросах / условных компиляциях для exe и dll mode.

Удачи.

Answer 2

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

Answer 3

Не совсем понимаю, почему нативный dll, вызываемый со стороны DotNet, может удвоить время обработки, если вы не можете дать более подробную информацию.

Однако, если нативная версия exe работает должным образом, вы можете запустить нативный exe-файл в качестве фонового процесса из DotNet, передавая параметры API через командную строку. Вы даже можете перенаправить вывод консоли exe в графический интерфейс на основе DotNet.

Answer 4

Действительно ли оболочка C ++ / CLI просто вызывает функцию DLL, или она загружает саму DLL, а затем останавливается и управляется .NET?Собственная процедура получает свой собственный поток или поток, созданный в контексте .NET?Моя интуиция заключается в том, что .NET делает что-то ненужное для управления временем жизни объекта, DLL или потока.

Поэтому я предлагаю добавить событие, чтобы указать, что DLL завершает свою работузапустите новый поток из собственной DLL, чтобы запустить процедуру, и немедленно верните дескриптор события.Пусть ваш .NET ждет этого дескриптора везде, где это уместно.

Answer 5

.NET Framework накладывает некоторые накладные расходы при обмене данными из своего «управляемого» кода с нативным или «неуправляемым» кодом. См. Здесь некоторую предысторию.

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