OT: recommended way of timing two pieces of code in C

[Patrick O'Callaghan]

On Fri, 2016-02-26 at 18:02 -0700, jd1008 wrote:
> > Note that the accuracy of this depends on several factors, such as
> how
> > long the measured interval is compared to the basic unit of
> timekeeping
> > (IOW if you want to measure the execution time of a short sequence
> of
> > instructions, you need to loop a few million times and divide the
> > result), and how much overhead is incurred in calling the timing
> > routines.
> >
> > poc
> Hi Patrick.
> Actually, no.
> Since the virtual timer is incremented only while the process is 
> actually running on the cpu, the time difference from when you first
> "start" the timer, and when you "stop" the timer
> (in Ranjan's case, just before exit), gives the most accurate time 
> possible on a system like linux.

Not what I meant. I know the system is only timing the process while
it's running, but there are still overheads to calling the timing
routines which count against the process (as they are running in user
state before entering the system and after exiting it). If the code of
interest is short compared to this, the overhead will skew the result,
but Ranjan hasn't said anything about the code to be measured so we
don't know if this matters or not. Eliminating these factors is
possible but tricky.

>  What Ranjan can do also, is to set the process scheduling class 
> to REALTIME (which
> is as approximate to REALTIME as a multiuser virtual mem system can 
> provide). Thus he will get a very accurate benchmark for the segment
> of code he wants to measure.

I doubt that will make any difference. As you said, the timers are
measuring process virtual time, so whether the process is scheduled
more or less frequently shouldn't matter.

poc