Re: New "make benchmark" target

[Eli Zaretskii]

> Date: Tue, 31 Dec 2024 04:00:05 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: acorallo@gnu.org, stefankangas@gmail.com, mattiase@acm.org, 
> eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> Date: Mon, 30 Dec 2024 17:25:44 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: acorallo@gnu.org, stefankangas@gmail.com, mattiase@acm.org, 
> >> eggert@cs.ucla.edu, emacs-devel@gnu.org
> >>
> >> "Eli Zaretskii" <eliz@gnu.org> writes:
> >>
> >> Top-posted TL;DR: let's call Andrea's code "make elisp-benchmarks" and
> >> include it now?  That would preserve the Git history and importantly (to
> >> me) reserve the name for now.
> >
> > Fine by me.
> 
> Pushed to scratch/elisp-benchmarks.

Thanks.

> Sorry for all the noise; we should really find a way to reduce
> emacs-diffs notifications when many commits are made at once.

I see no reason: people who subscribe to that list should be prepared
for floods from time to time.

> This branch:
> 
> 1. contains whitespace errors, because it contains the files precisely
> as they are in the elisp-benchmarks repo

We should probably clean that up, unless Andrea says that those
whitespace are somehow needed.

> >> And I don't usually run ERT tests individually, while I'm trying to get
> >> in the habit of running the (non-expensive) test suite before I push.
> >
> > I do it all the time, when I install some change and want to make sure
> > the related tests still pass.
> 
> Interesting: I find it very hard to localize my changes to specific
> tests, usually.

It is not a 100% reliable technique, but in 99% of the cases, running
the tests corresponding to the Lisp file(s) modified by a changeset,
followed by additional tests where Grep finds the functions in which
the changes were made, provide good coverage (if we have tests for
those features at all).