[Top][All Lists]
[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: |
Tue, 02 Oct 2012 23:17:54 +0200 |
> 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.
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Stefan Monnier, 2012/10/02
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Paul Eggert, 2012/10/02
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Eli Zaretskii, 2012/10/02
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Paul Eggert, 2012/10/02
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns.,
Eli Zaretskii <=
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Paul Eggert, 2012/10/03
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Eli Zaretskii, 2012/10/03
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Paul Eggert, 2012/10/03
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Eli Zaretskii, 2012/10/03
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Stefan Monnier, 2012/10/02
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Paul Eggert, 2012/10/03
- Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns., Stefan Monnier, 2012/10/03