Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns.

[Paul Eggert]

On 10/02/2012 10:03 AM, Eli Zaretskii wrote:
> To see what interval is actually being loaded into the timer, one
> needs to call getitimer after setitimer returns.

Yes, that would have been an improvement.  But it still wouldn't have
been right, as on many platforms (including mine) the actual sampling
interval differs from what timer_gettime / getitimer reports.  With a
CPU thread timer I can set the sampling interval to 1 ns (!), and
timer_gettime reports that it's 1 ns, but it's actually ~1 ms because
that's how thread scheduling works.  I believe the behavior
for this sort thing depends on which clock we're using, but I haven't
investigated it further.

> We can still translate that to time units, if we store the actual used
> CPU time with each sample, not the count of the theoretical sampling
> period.  I believe on Posix systems this boils down to calling
> clock_gettime with the correct timer ID

Yes, that should help, but I expect it'd slow things down.  On many
hosts clock_gettime is reasonably slow because it involves a system
call and whatnot.  In particular the realtime clock can be a
huge can of worms, due to multithreading and the desire to have
a consistent clock across threads, stuff that we don't care about
here but clock_gettime sometimes has to care about.

More generally, there is often a performance penalty in trying to get
the time precisely, and in profiling it's often more useful to get
the time quickly than to get it precisely.