Re: Time to merge scratch/correct-warning-pos into master, perhaps?

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> The branch scratch/correct-warning-pos is working and is almost
> finished.  Its intention is to get the byte compiler to report correct
> source positions in warnings and errors it emits.  It remains just to
> write some documentation about symbols with position and to fix any last
> minute bugs which turn up.
>
> There is a minor bug in test/lisp/emacs-lisp/comp-tests.el, which should
> be easier to resolve when Andrea is back again.
>
> To use it, just merge it and use it.  You shouldn't notice much
> difference.  If there are any byte compiler warning positions which
> remain uncorrect, please report them.
>
> Thie branch's predecessor was rejected in 2018 since it slowed down
> Emacs too much.  My benchmarks this afternoon show a much smaller
> slowdown, in the region of 1%.
>
> In these benchmarks, I used the following function:
>
>     (defun time-scroll-b (&optional arg)
>       (condition-case nil
>           (while t
>             (if arg (scroll-down) (scroll-up))
>             (sit-for 0))
>         (error nil)))
>
> in conjunction with benchmark-run in native-compiled Emacsen started
> with emacs -Q on buffer src/xdisp.c.  Both repositories were brought up
> to date yesterday evening, and master merged into the branch.
>
> Before each timing run I typed and deleted the character at the start of
> the buffer (to wipe out the fontification) and executed M-x
> garbage-collect.
>
> Here are the four timings I did on master:
>       o - (20.798601883 460 7.728701306)
>       o - (20.947118356 295 7.1172684969999995)
>       o - (20.941589929 293 7.144901186)
>       o - (20.917180235 293 7.136285445000002)
>
> ..  Here are the same four timings on scratch/correct-warning-pos):
>       o - (20.854543266 480 7.691123986)
>       o - (21.064465459 320 7.189660959000001)
>       o - (21.143813105 318 7.287708998000001)
>       o - (21.115932422 318 7.266432223999999)
>
> ..  It can be seen that the branch is around 1% slower than master.  This
> minor slowdown should be worth it to get correct positions in compile
> warning messages.
>
> So, I would propose to merge the branch into master now.  What do people
> (in particular Eli) say about this?

Hi Alan,

have you tried running elisp-benchmarks [1]?  I think this should give a
closer feedback on the perf impact of the execution engine.

Thanks

  Andrea

[1] <https://elpa.gnu.org/packages/elisp-benchmarks.html>