Так я экспериментировал с vsperfmon через инструменты vsperfreport/vsperfcmd командной строки с VS 2010. Я построил очень простую программу для профилирования и попытаться понять число этих инструментов вывод:Почему vsperfmon говорит мне, что включенное время вызываемой функции занимает больше времени, чем функция root?
void DoStuff()
{
double res = 0.0;
for (double i = 0.0; i < 10000.0; ++i)
{
res += sin(i);
}
printf("res is %lf", res);
}
int _tmain(int argc, _TCHAR* argv[])
{
DoStuff();
return 0;
}
I профилируйте исполняемый файл, выполнив шаги как подробно here в командной строке. Выше компилируется в perfPlay.exe, то я делаю следующие шаги:
vsinstr perfPlay.exe
vsperfcmd /start:trace /output:perfPlay.vsp
perfPlay.exe
vsperfcmd /shutdown
vsperfreport perfPlay.vsp /output:singleFile /summary:All
Вот странно, я не могу понять. Истекшее включительное время для DoStuff составляет менее включительно время для sin() в отчете о функции и вызывающем/вызываемом абоненте: Вот отчет о вызывающем/вызываемом для DoStuff(), обратите внимание на Elapsed Inclusive Time for THUNK: sin vs функция Root
Type Function Name Elapsed Inclusive Time Elapsed Exclusive Time Root DoStuffInLib(void) 2157487 0 Caller _wmain 2157487 0 2157487 0 Callee __RTC_CheckEsp 57 57 Callee _printf 347667 347667 Callee THUNK:sin 2282622 81435
Прошедшее включительно время определяется как количество времени, затраченного на выполнение кода в функции включая функции вы называете. По этому определению инклюзивное время DoStuff всегда должно быть> инклюзивным временем греха. Разница выше относительно небольшая, но если я позволю этой вещи работать некоторое время, она становится больше. Эта разница существует как в режимах Debug, так и Release.
Почему это так, что время греха выше? Я ожидаю, что он будет представлять часть времени записи Root. Я не совсем уверен, что происходит, или даже если я могу доверять этому инструменту, если он делает кажущуюся странную вещь. Я подозреваю, что я просто пропустил что-то, что сделало бы меня более ясными.
Таким образом, коррекция должна быть приблизительной, потому что нет возможности зондировать сами зонды (потому что для этого потребуется больше зондирования)? Поэтому они могут подумать, как долго делать что-то вроде QueryPerformanceCounter, чтобы взять вашу систему? Это правильное резюме? –
Я предполагаю, что это не только размер того, что вы профилируете, но и соотношение количества времени, затрачиваемого на ваш код, и частоты его профилирования. Код, который занимает мало времени, но часто профилируется, будет иметь более высокую ошибку измерения. –
Я думаю, вы поняли. –