[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44674: 28.0.50; Adding current-cpu-time for performance tests
From: |
Philipp Stephani |
Subject: |
bug#44674: 28.0.50; Adding current-cpu-time for performance tests |
Date: |
Mon, 16 Nov 2020 12:46:07 +0100 |
Am Mo., 16. Nov. 2020 um 09:19 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> On November 16, 2020 9:58:40 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
> > On November 16, 2020 3:07:35 AM GMT+02:00, Stefan Monnier
> > <monnier@iro.umontreal.ca> wrote:
> > > Package: Emacs
> > > Version: 28.0.50
> > >
> > >
> > > I tried to write a test for the performance problem seen in
> > bug#41029,
> > > but found it very difficult to make it work half-reliably because we
> > > only have access to wall-clock time from Elisp.
> > >
> > > So I suggest we add a new primitive `current-cpu-time` with which
> > > those
> > > tests seem to be at least somewhat doable.
> > >
> > > See my current patch below which includes a test for that
> > > performance bug. It clearly requires adding w32 support (or
> > > fetching more clock functionality from gnulib) but I don't know how
> > to
> > > do that.
> >
> > AFAIU, using 'clock' here is not the best idea, as there are caveats
> > wrt to calling 'system', and the origin of the returned value is not
> > well defined to be portable.
> >
> > I suggest to use 'times' instead. For w32, we could easily implement
> > it, as we already have that functionality for 'getloadavg'.
>
> Btw, once this goes in, how about making benchmark-run use it?
>
benchmark-run measures walltime, not CPU time, it should use CLOCK_MONOTONIC.
We might consider adding another macro that returns the CPU time (or both).
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Mattias Engdegård, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Stefan Monnier, 2020/11/16