Итак, я экспериментировал с vsperfmon с помощью инструментов командной строки vsperfreport / vsperfcmd с VS 2010. Я создал очень простую программу для профилирования и попытался понять числа, которые эти инструменты выводят:
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;
}
Я профилирую исполняемый файл, выполнив шаги, как описано здесь в командной строке.Выше скомпилировано в 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 (), обратите внимание на Истекшее включенное время для 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
Истекшее включительно время определяется как количество времени, затрачиваемое на выполнение кода в вашей функции , включая функции, которые вы вызываете .Согласно этому определению, время, в котором учится Дестуфф, всегда должно быть> временем, включающим грех.Разница выше относительно невелика, но если я позволю этой вещи работать некоторое время, она станет больше.Это различие существует как в режимах отладки, так и в режиме выпуска.
Почему время греховности выше?Я ожидал бы, что это представит часть времени Корневой записи.Я не совсем уверен, что происходит, и даже если я могу доверять этому инструменту, если он делает, казалось бы, странные вещи.Хотя я подозреваю, что мне просто не хватает чего-то, что могло бы прояснить для меня.