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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

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).