views:

297

answers:

6

I'm doing some prototyping work in C, and I want to compare how long a program takes to complete with various small modifications.

I've been using clock; from K&R:

clock returns the processor time used by the program since the beginning of execution, or -1 if unavailable.

This seems sensible to me, and has been giving results which broadly match my expectations. But is there something better to use to see what modifications improve/worsen the efficiency of my code?

Update: I'm interested in both Windows and Linux here; something that works on both would be ideal.

Update 2: I'm less interested in profiling a complex problem than total run time/clock cycles used for a simple program from start to finish—I already know which parts of my program are slow. clock appears to fit this bill, but I don't know how vulnerable it is to, for example, other processes running in the background and chewing up processor time.

+1  A: 

In POSIX (e.g. on Linux), you can use gettimeofday() to get higher-precision timing values (microseconds).

In Win32, QueryPerformanceCounter() is popular.

Beware of CPU clock-changing effects, if your CPU decides to clock down during the test, results may be skewed.

unwind
+1  A: 

There's a kind of tool called a "profiler"; there are also other APIs with a higher resolution than (i.e. more accurate than) clock.

Which O/S are you using?

ChrisW
As I've just updated the question: I'm interested in both Linux and Windows, and things that work on both are ideal.
me_and
+2  A: 

For a rough measurement of overall running time, there's time ./myprog.

But for performance measurement, you should be using a profiler. For GCC, there is gprof.

This is both assuming a Unix-ish environment. I'm sure there are similar tools for Windows, but I'm not familiar with them.

Edit: For clarification: I do advise against using any gettime() style functions in your code. Profilers have been developed over decades to do the job you are trying to do with five lines of code, and provide a much more powerful, versatile, valuable, and fool-proof way to find out where your code spends its cycles.

DevSolar
A: 

If you can use POSIX functions, have a look at clock_gettime. I found an example from a quick google search on how to use it. To measure processor time taken by your program, you need to pass CLOCK_PROCESS_CPUTIME_ID as the first argument to clock_gettime, if your system supports it. Since clock_gettime uses struct timespec, you can probably get useful nanosecond resolution.

As others have said, for any serious profiling work, you will need to use a dedicated profiler.

Alok
+3  A: 

Forget time() functions, what you need is:

Valgrind!

And KCachegrind is the best gui for examining callgrind profiling stats. In the past I have ported applications to linux just so I could use these tools for profiling.

Autopulated
+1  A: 

I've found that timing programs, and finding things to optimize, are two different problems, and for both of them I personally prefer low-tech.

For timing, the trick is to make it take long enough by wrapping a loop around it. For example, if you iterate an operation 1000 times and time it with a stopwatch, then seconds become milliseconds when you remove the loop.

For finding things to optimize, there are pieces of code (terminal instructions and function calls) that are responsible for various fractions of the time. During that time, they are exposed on the stack. So you can wrap a loop around the program to make it take long enough, and then take stackshots. The code to optimize will jump out at you.

Mike Dunlavey
+1 for looping to make the duration longer, and I wish I could add another +1 for the last paragraph.
ChrisW
@ChrisW: Biologists call this "amplifying the signal", when they make millions of copies of a piece of DNA so they can read it.
Mike Dunlavey