2012-02-17 4 views
1

Так я экспериментировал с 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. Я не совсем уверен, что происходит, или даже если я могу доверять этому инструменту, если он делает кажущуюся странную вещь. Я подозреваю, что я просто пропустил что-то, что сделало бы меня более ясными.

ответ

3

Монитор производительности использует зонды для сбора данных. Он пытается вычесть время, затраченное его собственными пробниками из собранных данных, но эта коррекция является приблизительной и часто будет последовательно отключена в одном или другом направлении. Как правило, чем меньше функция, которую вы пытаетесь зондировать, тем более неточные измерения, потому что время, затрачиваемое на сбор данных, является более высоким процентом прошедшего времени.

+0

Таким образом, коррекция должна быть приблизительной, потому что нет возможности зондировать сами зонды (потому что для этого потребуется больше зондирования)? Поэтому они могут подумать, как долго делать что-то вроде QueryPerformanceCounter, чтобы взять вашу систему? Это правильное резюме? –

+0

Я предполагаю, что это не только размер того, что вы профилируете, но и соотношение количества времени, затрачиваемого на ваш код, и частоты его профилирования. Код, который занимает мало времени, но часто профилируется, будет иметь более высокую ошибку измерения. –

+0

Я думаю, вы поняли. –