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

[Eli Zaretskii]

> Date: Tue, 02 Oct 2012 13:52:40 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden
> 
> 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.

Does getitimer report correct values for reasonable intervals, though?
If it does, that will be good enough for our needs.

> > 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.

We could call clock_gettime once in 10 or 100 samples, say.  Its
results are cumulative, so for short periods of time, like 0.1 or 1
sec, they are still suitable for converting sample numbers to CPU
times, by assuming uniform CPU percentage over that period.

> 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.

Yes, but showing a vague "number of samples" is hardly useful enough.
Maybe we should do the above as an option, and see if it's good enough
and preferred.