I have tried using clock() [in time.h] to time function execution time, but getting 0 out of it b/c it may not be precise enough. Is there a clock function that has a higher precision than clock()? Thanks.
I have tried using clock() [in time.h] to time function execution time, but getting 0 out of it b/c it may not be precise enough. Is there a clock function that has a higher precision than clock()? Thanks.
With standard C/C++, there's no real way.
But if you're on Windows: http://cboard.cprogramming.com/showp...7&postcount=27
And there are ways to do this on other platforms as well. Try googling for more information.
FWIW, you can often just run your code in a loop say 1000 times, and then it will take long enough for clock() to measure its runtime.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
I saw in the link that you have previously written. I don't want to purposely add delays to the functions in order to find out the performance. I'm also investigating the use of a profiler. Would it be compiler specific in terms of that information (I'm writing mex-file generating C++ code that is used on Matlab)?
I'm not quite sure what you're asking. Profiling information is definitely compiler-specific, and run-specific as well. But it's still very useful nevertheless; profiling can tell you the bottlenecks in your code.
If you're compiling with gcc, you can use its profiler, gprof. cpwiki.sf.net/gprof
What exactly are you trying to do? Figure out what is slowing down your program so that you can improve its perfomance?
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
I'm compiling with Microsoft Visual Studio 2005 compiler in Matlab environment. I'm trying to figure out which function I have in a project that is running the slowest so that I can start improving the performance by spending the effort optimizing that function.
Then a profiler is exactly what you need.
Unfortunately I've never done any profiling with Visual Studio, so I can't really help you there. I can only suggest google, and this site, which looks like it might be useful.
http://blogs.interknowlogy.com/adamc.../08/22470.aspx
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
The thing is I'm not sure whether I should be using a profiler in Visual Studio 2005 or Matlab. I have trouble finding profiler information that are helpful with google before I asked the question on this forum already. Anyhow, I guess I can keep searching and asking for help on finding the information until I find what I'm looking for. Thanks anyway.
A sampling profiler (oprofile for Linux, or VTune(Intel)/CodeAnalyst(AMD) for Windows) is often better than gprof that instrument the code - the reason being that the instrumentation adds to the run-time, and doesn't necessarily show the actual time spent in each function.
The sampling profiler will sample the program counter (where in the code you are) on each timer-tick, which usually gives a good picture of where your code is spending most of it's time.
Another option is of course to use clock() over a bigger function. But instrumenting the code to run a 1000 (or 1000000) loops of something you want to see how fast it is, is often a good plan that works well - and then clock() is good enough.
There are also other higher precision timing methods - TSC is one of the most precise ones, as it gives you a clock-cycle accurate time [2GHz clock on a 2GHz processor, for example]. http://en.wikipedia.org/wiki/Time_Stamp_Counter
However, there are some small problems, particularly if your machine has multiple processors - you may want to force your thread to run on a single processor, e.g. SetThreadAffinityMask.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.