Блог

У меня есть программа, которая содержит функцию fast_write() , которая полностью является оболочкой WriteConsole() (вывод на консоль Windows). Программа генерирует много консольных выходных данных и записывает их. При профилировании с помощью профилировщика Visual Studio (профилировщик выборки) и Трейси (профилировщик синхронизации) результаты значительно отличаются.

Трейси показывает, что эта функция занимает большую часть времени (~82%), в то время как VS показывает ее на уровне 6% или около того.

Как такое может быть? Я знаю, что (если Трейси права) большинство образцов не попадут в «мой код». И это заставило меня понять, что я действительно не понимаю, как профилировщики выборки сопоставляют такие образцы с кодом. Но я бы предположил, что если VS показывает процент — это правильно.

Копая глубже с Трейси, я вижу , что во fast_print() время, conhost.exe занимает большую часть времени. Это еще больше подтверждает теорию о том, что Трейси права.

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

Обратите внимание, что я также попытался загрузить символы с сервера символов, но это не изменило количество выборок в VS.

редактировать: Я вручную подтвердил, что fast_print() на самом деле требуется 80% процентов, просто позвонив дважды и выполнив некоторые вычисления. Это все еще оставляет меня с огромным вопросом: они не могут этого сделать, верно? Они не могут просто неправильно атрибутировать эти образцы без каких-либо указаний?!

редактировать: VTune также сообщает о тех же результатах, что и Трейси. Так что это только против того, чтобы все испортить.