emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when prof


From: Eli Zaretskii
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns.
Date: Wed, 03 Oct 2012 19:18:01 +0200

> Date: Tue, 02 Oct 2012 22:00:13 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden
> 
> On 10/02/2012 02:17 PM, Eli Zaretskii wrote:
> 
> > Does getitimer report correct values for reasonable intervals, though?
> 
> No, I'm afraid it does the same thing for larger intervals that it
> does for tiny ones.  That is, it doesn't tell you the interval
> that is actually used.

Too bad, I thought modern Posix implementations are cleaner.

At least at some point in the past (Jul 1999, according to 'cvs
annotate'), some configure-time tests or maybe some Unix program
expected setitimer to round up the small time values to the smallest
supported values.  I know that because I coded that logic into the
DJGPP implementation of 'setitimer', with a comment which says:

 /* Posix systems expect timer values smaller than the resolution of
    the system clock be rounded up to the clock resolution.  */

> > We could call clock_gettime once in 10 or 100 samples, say.
> 
> Why bother?  Call it once at the start of the run, and
> once at the end.  That's enough to give us an average.

This will certainly be better than no time at all, although it could
skew the results in some situations.  E.g., imagine that 30% of the
elapsed time that passed while profiling Emacs got very little or no
CPU time -- this could potentially identify some innocent function as
a hot spot, just because Emacs was stuck in it, waiting to be
scheduled.

> > showing a vague "number of samples" is hardly useful enough.
> 
> It'd be easy to replace "CPU samples" with something like
> "CPU samples (10 ms)", to give users a feel for what
> the nominal sample size is.

I think using even a single measurement from clock_gettime will be
much better.

So how about a new primitive that would return the information from
clock_gettime (or getrusage, if clock_gettime is not available), which
profiler.el could then use to convert timer ticks into seconds?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]