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

[Eli Zaretskii]

> Date: Tue, 02 Oct 2012 09:37:36 -0700
> From: Paul Eggert <address@hidden>
> Cc: address@hidden
> 
> On 10/02/2012 06:20 AM, Stefan Monnier wrote:
> > They were (or close enough) since each sample was weighted according to
> > current_sampling_interval.
> 
> On Windows they weren't.  Apparently the sampling interval there
> is actually 15 ms, even though we pretended it was 1 ms.

Which AFAIK is (was) a bug in profiler: it cannot assume that what it
asked setitimer will actually be obeyed.  To see what interval is
actually being loaded into the timer, one needs to call getitimer
after setitimer returns.

> > we have the new problem that
> > starting/stopping/starting/stopping won't count correctly if
> > profiler-sampling-interval is modified between the two profiler-start.
> 
> True.  That's partly why the profiler report
> now says "CPU samples".  Truth in advertising....

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 (and there are equivalent APIs
on MS-Windows).  Then we could satisfy Stefan's design goal of having
compatible profiles with different sampling period.  As a nice bonus,
this will also handle more accurate the situation whereby the system
is heavily loaded, and therefore SIGPROF is delivered with a
significant delay.