How to measure the time that a piece of code takes to execute?

Question

Suppose I want to measure the time that a certain piece of code takes. For that I would normally do something like this

clock_t startTime = clock();
//do stuff
//do stuff
//do stuff
//do stuff
float secsElapsed = (float)(clock() - startTime)/CLOCKS_PER_SEC;

What if the program is multithreaded and context switches occur within the part which I want to measure? How would I measure the time that my code takes to execute excluding time spent on other threads? Even if there are tools that do it, I would very much like to know how they're doing it.

Zeist

do you want wall clock time ? Or actual time spent on the cpu by that one thread ? Note that both are quite different - even for single-threaded applications. – Genteel

You could see if your platform supports CLOCK_THREAD_CPUTIME_ID - this in theory (I've not tested it myself) should report the time specific to that thread. – Disillusionize

@Sander: Time spent on the cpu by that thread, I suppose – Zeist

@Armen, so dark ages.. ;) Why don't you use QueryPerformanceCounter? AFAIK, you have to pin the thread to a specific CPU to get best results though (SetThreadAffinityMask) - not sure how the windows scheduler works, but on linux you can control which cores the scheduler uses and which it can't so you can guarantee that the core you're using will not be used by the scheduler (and therefore your thread interrupted)... – Disillusionize

Parhaps this thread may help. GetThreadTimes API funciton may come handy, unless you're measuring CPU cycles. – Cobol

Answer 1

There are different ways to measure how long code takes to execute.

If you are interested in the relative performance of certain functions, a profiler is the only way to go. Note that this will de-emphasise the impact of blocking I/O due to the computation overheads it induces.

If you want the clock-based time of certain functions, there are loads of options.

Personally I would say gettimeofday is sufficient.

If you want to get precise, use RDTSC

If you want to get really precise, you'll want something like this

t1 = rdtsc();
t2 = rdtsc();
my_code();
t3 = rdtsc();
my_code_time = (t3-t2) - (t2-t1)

You will need to repeat this block to account for thread scheduling discrepencies, and also pay attention to cacheing effects.

Mcpherson

Answer 2

This is why code benchmarking basically sucks- because you can't know how long it takes. Things like being pre-empted by the OS are unpredictable at best. Use a professional profiler, as they may have code in them that can deal with these problems, or don't bother. Writing clock() style things is utterly meaningless.

Majolica

You can (on Linux at least) mark the thread as real-time. Further to that you can use cpu affinity and segregate off a core just for your test. Usually you don't need this absolute guarantee for profiling, but in some cases it can help. – Glamorize

Answer 3

From the Linux terminal use 'time path_to_app'

This will return everything you want to know.

Fiber

Answer 4

I have prepared two very simple classes. The first one ProfileHelper the class populate the start time in the constructor and the end time in the destructor. The second class ProfileHelperStatistic is a container with extra statistical capability (a std::multimap + few methods to return average, standard deviation and other funny stuff).

I have used this idea often for profiling. I guess you could make it work even in a multi-thread environment. It will require a bit of work, but I don't think it will be so difficult.

Have a look at this question for more information C++ Benchmark tool.

Thickwitted