StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Unfortunately this is not such an easy task.</p> <p>As previously mentioned QueryPerformanceCounter is a viable choice.<br> Other possibilities are:<br> - <strong>GetTickCount</strong> (not advisable, since its accuracy is worse than 30ms)<br> - <strong>timeGetTime</strong>: By default it has a 15ms accuracy. This corresponds to the default time allocated by the task scheduler (15ms on my computer). You can force timeGetTime to be more accurate, by changing a system wide setting that rules the time allocated by the scheduler : a call to timeBeginPeriod can do this. However, this should only be used as a temporary system hack! Please do not use it in your release code!<br> - <strong>Query the processor's time stamp counter</strong> : this requires assembler programming and I would not recommend it.</p> <p>As far as QueryPerformanceCounter is concerned, you can find an easy to use wrapper here : <a href="http://www.codeproject.com/KB/datetime/perftimer.aspx" rel="nofollow">http://www.codeproject.com/KB/datetime/perftimer.aspx</a></p> <p>You can use it this way : </p> <pre><code>CPerfTimer t; t.Start(); CallExpensiveTask(); std::cout << "Time (ms) " << t.Elapsedms(); </code></pre> <p>A few advices however : </p> <ul> <li> As mentionned, run your function a lot of times in order to get a reliable measure <li> Beware of the task scheduler : On an average computer each process is given 15ms before switching to another process. If the task scheduler switches task during the call to your measured function, you might measure a time that is much higher (around 15ms higher) <li> Note that sleep(1) yields to a 15ms pause (since the scheduler will switch to a different process) <li> Remember that QueryPerformanceCounter can (rarely) give inaccurate results : On multicore processors, you might sometimes see a negative time lapse (!). In that case, you should redo your measure (see http://www.virtualdub.org/blog/pivot/entry.php?id=106 ) <li> Temporary solutions to counteract the scheduler effect: - Raise your process priority (you can do it through the task manager) - Hack the scheduler : the timeBeginPeriod (http://msdn.microsoft.com/en-us/library/dd757624(v=VS.85).aspx) provided by microsoft has the power to change the time allocated to each task from 15ms to lower values (remember to not include this is your release code, since this is a system wide setting that can reduce the global performance...) </ul> <p><strong>Some more notes about the processor's time stamp counter</strong> </p> <ul> <li> I did not test its accuracy myself, but http://en.wikipedia.org/wiki/Time_Stamp_Counter is a good source of information about it, and about its limitations (esp. on multicore processors, and also on processors with variable clock frequencies) <li> AFAIK, it is advisable to use this kind of timer on a single thread for which you set the processor affinity <li> An example of implementation (found at http://developer.nvidia.com/object/timer_function_performance.html) could be: </ul> <pre><code>#pragma warning (disable : 4035) // disable no return value warning __forceinline DWORD GetPentiumCounter() { __asm { xor eax,eax // VC won't realize that eax is modified w/out this // instruction to modify the val. // Problem shows up in release mode builds _emit 0x0F // Pentium high-freq counter to edx;eax _emit 0x31 // only care about low 32 bits in eax xor edx,edx // so VC gets that edx is modified } } #pragma warning (pop) </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload