Я создал графическую библиотеку для игр. Моя тестовая демонстрация работает со скоростью 60 кадров в секунду. Когда я запускаю эту демонстрационную версию со статической версией моей библиотеки, она занимает 2-3% процессора в taskmanager. Когда я использую версию DLL, она использует около 13-15%. Это нормально? Так, как я мог его оптимизировать? Я уже просил использовать /O 2 для большей функциональности.
Является ли DLL медленнее, чем статическая ссылка?
Ответ 1
Не запускайте свой таймер производительности, пока DLL не сможет выполнить свою функцию один раз. Это дает время для загрузки в память. Затем запустите таймер и проверьте производительность. Затем он должен в основном соответствовать таковому из статического lib.
Также имейте в виду, что расположение загрузки DLL может значительно повлиять на скорость загрузки. Базовые addres для DLL по умолчанию - 0x400000. Если у вас уже есть какая-то другая DLL в этом месте, тогда процесс загрузки должен выполнить дорогостоящий шаг повторной адресации, который еще больше снизит ваше время.
Если у вас есть такой конфликт, просто выберите другой базовый адрес в Visual Studio.
Ответ 2
У вас будут накладные расходы на загрузку DLL (должно быть только один раз в начале). Он не статически связан с прямыми вызовами, поэтому я бы ожидал небольшого количества накладных расходов, но не много.
Однако некоторые библиотеки DLL будут иметь гораздо более высокие накладные расходы. Я думаю о COM-объектах, хотя могут быть и другие примеры. COM добавляет много накладных расходов на вызовы функций между объектами.
Ответ 3
Если вы вызываете DLL-функции, они не могут быть встроены для вызывающего. Вы должны немного подумать о своих DLL-границах.
Может быть, для вашего приложения лучше иметь небольшой загрузочный exe, который просто выполняет основной цикл в вашей DLL. Таким образом, вы можете избежать больших накладных расходов для вызовов функций.
Ответ 4
Немного неясно, что статически/динамически связано. Является ли DLL вашей библиотеки статически связанной с ее зависимостями? Возможно ли, что DLL вызывает другие DLL (что будет медленным)? Возможно, попробуйте запустить профилировщик из valgrind в вашем исполняемом файле, чтобы определить, откуда исходит вся загрузка процессора.