Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.

[Alan Mackenzie <acm@muc.de>]

Hello again, Gemini.

On Mon, Nov 26, 2018 at 08:14:28 -0800, Gemini Lasswell wrote:
> Alan Mackenzie <acm@muc.de> writes:

> Hi Alan,

> > syntax-tasks-{backward,forward}-word presumably time backward-word and
> > forward-word.  bytecomp-tasks-compile-doc I'm not sure about, is that
> > the extraction of doc strings from .elc files?

> You are correct about syntax-tasks-*.  bytecomp-tasks-compile-doc
> measures the time it takes to compile the function 'doctor-doc' from
> doctor.el (since I want benchmark tasks to run in old versions of Emacs,
> I went looking in lisp/play for something that hadn't changed in a long
> time.)

Ah, "doc" as in "doctor", not "document".  :-)

When I compile doctor.el with (time-it (byte-compile-file
".../play/doctor.el")), I see a slow down of 9.9%, which is surprisingly
little, given how much extra processing is involved when
symbols-with-positions-enabled is bound to non-nil.

Compiling a single function from that file, you see a 24% slowdown (if I
remember the figures correctly).  There's some explaining to do there to
account for the difference between what we see.

My machine is a desktop with an AMD Ryzen processor, and I run Gentoo
GNU/Linux.  Maybe the processor architecture accounts for some of the
difference.

> > After getting over my knee-jerk reaction, my thoughts are that these
> > timings are not of things which, of themselves, would directly concern a
> > user.  A fill-paragraph will take 15% more time, but would a user
> > actually notice this, given that the operation is usually instantaneous?

> > Good things to benchmark would be interactive commands which feel a bit
> > sluggish anyway.  CC Mode redisplay is a good candidate for this (see
> > below).  ;-)

> > From your timings, my gut feeling is that the 15% slowdown in
> > fill-tasks-fill-paragraph probably represents fairly closely the
> > slowdown in Emacs as a whole.  It is testing a "macro" operation rather
> > than an isolated primitive.

> Every time I use a keyboard macro to edit every line in a file, I wonder
> why it takes so long.  kmacro-tasks-edit-lines changes 10 lines of
> "1. Flintstone, Fred" to read "Fred Flintstone" using basic editing
> commands.  From the current short list of benchmarks, it would be my
> choice for representing Emacs as a whole.

That one was 18%.  I think it would be a fair summary to say that you
are seeing a 15 - 20% slowdown in "real life" measurements (which
excludes the byte compilation, which everybody agrees can take as long
as it likes).  I seem to be seeing a lesser slowdown, of around 10%,
although I haven't yet got around to running your new branch and doing a
solid test.

Quite likely, Eli is keeping a keen eye on this part of the thread to
see how things develop.  ;-)  My feeling is that the new branch is up to
being integrated into master eventually, with "only" 10 - 20% slowdown,
but then I'm not exactly impartial.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).