2

I looked through old threads but could not find the answer to my question:

How can I time the body of my function inside a C program?

samoz
  • 56,849
  • 55
  • 141
  • 195
  • 3
    Don't worry, SO can be a hard site to search. It's usually better to just have google filter the results to the site instead: http://www.google.com/search?q=site%3Astackoverflow.com+profile+c+function – GManNickG Jul 31 '09 at 01:38

5 Answers5

13

A simple method is to use the 'clock' function:

#include <time.h>

clock_t start, end;
double cpu_time_used;

start = clock();
... /* Do whatever you want to time */
end = clock();
cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;

Or if you're on linux you can use the 'time' command to time how long it takes your app to execute; this doesn't allow you to time a specific code section though, and includes time taken to initiate the process etc.

time ./myapp

Edit: This is very much a basic 'hack-in-a-quick-timer' approach. For true performance profiling you want to look at a proper profiler, as suggested by Larry Watanabe.

CapBBeard
  • 978
  • 10
  • 22
  • Very insignificant, but how much time do you think it adds to call end = clock()? In the online competitions where you have 1-2 seconds for your program to execute, that could actually be significant. – jkeys Jul 31 '09 at 01:47
  • 1
    It's easy to see the overhead: just call 'start = clock(); end = clock();' and see the difference (if it's measurable). – Edmund Jul 31 '09 at 01:49
  • I cant imagine it would add much, at least with current compilers and optimisation etc. I'd expect anything you would be timing in this manner would be orders of magnitude slower than calling clock(). – CapBBeard Jul 31 '09 at 01:54
  • @Larry interesting thought, as I'm spawning 10,000 threads between the clock calls. Would a call to pthread_join be what I'm looking for? – samoz Jul 31 '09 at 02:12
  • See my answer below - the answer is just to use a profiling tool. – Larry Watanabe Jul 31 '09 at 13:35
  • @Hooked: This isn't the sort of thing you should be leaving in "production" (competition-ready) code. I'd stick it inside an `#ifdef TIMING` or similar. – TMN Jan 25 '10 at 17:50
2

It depends on your compiler and OS. On Sun workstations, I used to use "prof" or "gprof". There is surely a profiling tool for your compiler, OS, and machine - just google "C profile yourOS yourcompiler" (substitute the name of your OS and your compiler )

Larry Watanabe
  • 10,126
  • 9
  • 43
  • 46
  • +1 as this truly a better way of profiling your code as the clock method does not account for threads, interupts and other vectors that the kernel controls. – Wayne Jul 31 '09 at 01:50
  • I agree - and also, what's the point of measuring the time of just 1 specific function? If you profile the whole thing then you will find out what the bottlenecks are, which is more important -- unless it's just a case of CYA for YOUR part of the project – Larry Watanabe Jul 31 '09 at 01:55
2

The basic method is using the clock() function, that is where we all started.

Ex.:


clock_t start = clock();
/* Your code */
printf("Time elapsed: %f\n", ((double)clock() - start) / CLOCKS_PER_SEC);

However, when you start learning about Operating systems, hardware, schedulers, multi-threading, etc. You realized that execution time is something very subjective. When you want to measure performance (which does not necessarily mean execution time) then you need more robust tools.

Gprof is a really easy to use C profiler, which could help you understand better the concept of performance.

Freddy
  • 3,064
  • 3
  • 26
  • 27
2
time ./a.out

run above one, and output will be:

real    0m0.017s
user    0m0.017s
sys 0m0.000s

real: Total end to end time taken by program/command

user: Time taken in user mode.

sys: Time taken in kernel mode

Shivam
  • 192
  • 1
  • 12
0

Not sure about specific functions names in C, but a common practice is to store a microsecond timestamp before the body starts, then grab another one at the end and subtract.

Alex S
  • 25,241
  • 18
  • 52
  • 63