Re: Correct byte compiler error/warning positions. The solution!

[Alan Mackenzie]

Hello, Eli.

Ping?

On Mon, Nov 29, 2021 at 19:39:05 +0000, Alan Mackenzie wrote:
> On Mon, Nov 29, 2021 at 14:45:01 +0200, Eli Zaretskii wrote:
> > > Date: Mon, 29 Nov 2021 11:50:19 +0000
> > > From: Alan Mackenzie <acm@muc.de>
> > > Cc: emacs-devel@gnu.org

> > > Anyhow, I've committed the current state in the new branch
> > > scratch/correct-warning-pos.  It should build and run OK, although I
> > > haven't tried it out with native compilation, yet.  It is marginally
> > > slower than master.  Maybe we can merge it into master some time for
> > > Emacs 29.

> > Please show the benchmark results, so we could know how slower is
> > this.

> The source for the benchmarking is:

> (defun time-scroll-b (&optional arg)    ; For use in `benchmark-run'.
>   (condition-case nil
>       (while t
>         (if arg (scroll-down) (scroll-up))
>         (sit-for 0))
>     (error nil)))

> I ran (benchmark-run (time-scroll-b)) five times on both versions of
> Emacs, using the file src/xdisp.c from the version being tested, and
> running on a Linux tty.  Between each run I did M-<, SPACE, pause ~5
> seconds, C-_.

> On the master branch I got the following timings:

>     * - 1: (20.146470262 435 7.018855274999999)
>     * - 2: (20.6936481 307 6.8447708129999985)
>     * - 3: (20.748953179999997 303 6.931802685000001)
>     * - 4: (20.754181744 303 6.932338166000001)
>     * - 5: (20.746469523000002 304 6.927925281999997)

> On the scratch/correct-warning-pos branch, I got these:

>     * - 1: (20.200789011 446 7.2819411899999995)
>     * - 2: (20.837616185999998 308 6.967083439000001)
>     * - 3: (20.93961052 305 7.074547531)
>     * - 4: (20.931170864 305 7.0736086979999975)
>     * - 5: (20.853407755 304 7.029190317999998)

> So, on this test the new branch appears to be around 1%, perhaps a
> little less, slower than the master branch.

> It is notable that the first run in each version is different from the
> others, both in being a little faster, and having far more
> garbage-collections.  I don't know why this is.  Maybe Emacs could be
> marginally sped up by garbage collecting more frequently, but that's
> speculation.

> > Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).