Профилирование плагина dll

Question

Я хочу профилировать плагин DLL в C ++. У меня есть доступ к источнику (будучи автором / помощником) и я могу изменять их (если это необходимо для инструментовки). То, что у меня нет, это источник / символы / и т.д. хост-программы, которая вызывает DLL. У меня есть только заголовки, необходимые для сборки плагина. DLL вызывается при действии клиента.

Как лучше всего приступить к профилированию кода? Нереально «оборачивать» исполняемый файл вокруг dll, и это было бы бесполезно, поскольку, поскольку в плагине я вызываю некоторые функции с хоста И мне нужно профилировать эти пути, оболочка может исказить производительность.

РЕДАКТИРОВАТЬ после комментария Киерена Джонстона: В идеале я хотел бы подключиться к загруженному dll так же, как это умеет отладчик (присоединение к запущенному процессу хоста и размещение точки останова где-то в dll по мере необходимости) , Является ли это возможным? Если нет, мне нужно будет задать еще один вопрос, чтобы спросить, почему: -)

Я использую TFS-версию Visual Studio 2010.

Бонусные баллы за предоставление предложений / ответов для одной и той же задачи в AIX (ах, радости от нескольких сред!).

Answer 1

Это возможно, хотя и немного раздражает.

1. Разверните свою подключаемую библиотеку DLL там, где она требуется хост-приложению
2. Запустите хост-приложение и убедитесь, что оно использует ваш плагин
3. Создать новую сессию производительности
4. Добавьте хост EXE в качестве цели в сеансе с шага 3
5. Выберите семплинг или инструментарий для вашей сессии
6. Запустить сеанс профилирования

Во время всего этого держите ваш плагин загруженным, и VS должен автоматически найти символы для вашего плагина.

Answer 2

Не уверен насчет VS10, но в старых вы отлаживаете dll, определяя исполняемый файл для его запуска.

Давайте разделим проблему на две части: 1) определение того, что вы могли бы назвать «узкими местами»,и 2) измерить общее ускорение, которое вы получаете, исправляя каждое из них.

(2) легко, верно?Все, что вам нужно, это внешний таймер.

То есть (1).Если вы похожи на большинство людей, вы думаете, что найти «узкие места» невозможно без какого-либо точного хронометража частей программы.Это не так, потому что в большинстве случаев вещи, которые нужно исправить, чтобы добиться наибольшего ускорения, - это не то, что вы можете обнаружить таким образом.Они не обязательно являются плохими алгоритмами, медленными функциями или горячими точками.Это распределенные вещи, выполняемые совершенно невинно выглядящим, хорошо спроектированным кодом, которые просто предоставляют огромную возможность ускорения, если кодируются по-другому.

Вот пример , где достаточно хорошовремя выполнения письменной программы сократилось с 48 секунд до 20, 17, 13, 10, 7, 4, 2.1 и, наконец, 1.1, за 8 итераций. ** Это суммарный коэффициент ускорения более 40x.Коэффициент ускорения, который вы можете получить, отличается в каждой отдельной программе - некоторые могут получить меньше, некоторые могут получить больше, в зависимости от того, насколько они близки к оптимальному в первую очередь.Там нет загадки, как это сделать.Метод был случайная пауза .(Это альтернатива использованию профилировщика. Профилировщики измеряют различные вещи и дают вам различные подсказки, которые могут или не могут быть полезны, но они не могут точно сказать вам, в чем проблема.)

**Достигнутые коэффициенты ускорения за одну итерацию составили 2,38, 1,18, 1,31, 1,30, 1,43, 1,75, 1,90, 1,91.Еще один способ выразить это - процентное сокращение времени на каждой итерации: 58%, 15%, 24%, 23%, 30%, 43%, 48%, 48%.Я испытываю трудности с поклонниками профилировщика, потому что метод очень ручной, но они никогда не говорят о результатах ускорения.(Может быть, это изменится.)