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

[Alan Mackenzie <acm@muc.de>]

Hello, Gemini.

On Sun, Nov 25, 2018 at 10:48:38 -0800, Gemini Lasswell wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > The branch scratch/accurate-warning-pos now bootstraps.  (It also now
> > runs on optimised builds. ;-)
> >
> > Its bootstrap is a mere 7.1% slower than master's.

> Hi Alan,

> Great progress!  There are clearly benefits to Emacs Lisp programmers
> (especially if errors and debugger backtraces can someday have accurate
> source positions), to be weighed against the cost of a slower Emacs for
> all the non-Lisp programmers and non-programmers who work with Emacs.  I
> don't know how to begin to sort that out, but since I've been working on
> creating a benchmark suite for Emacs, I'm thrilled you've given me such
> an interesting test case. :)

:-)

> Here's how much longer in percentage terms the tasks in my nascent
> benchmark suite take in your branch compared to 5b218be0c3, the commit
> your branch is based on, running on my newish Linux laptop.  I'll push
> my benchmarking project to a scratch branch soon so you can see the code
> which was benchmarked.

> cus-theme-tasks-load-tango: 9%
> bytecomp-tasks-compile-doc: 24%
> kmacro-tasks-edit-lines: 18%
> fill-tasks-fill-paragraph: 15%
> cmds-tasks-forward-line: 5%
> data-tasks-prime-p: 1%
> emacs-tasks-startup: 4%
> syntax-tasks-backward-word: 23%
> syntax-tasks-forward-word: 20%

Ouch!  That's slower than I had anticipated or measured myself.

From this point on, I probably look a bit defensive.  Forgive me for
this.

I'm guessing what each benchmark tested.  I see you've pushed a scratch
branch for this, but I haven't looked at this yet.

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?

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.

> Here's a benchmark report, which contains the measurements from which I
> calculated those percentages:

[ .... ]

> Each timing value in this file is the average of 30 runs of the task.
> Here's the same report, exported with graphs from gnuplot (and page
> breaks in the wrong places):

Thanks for doing this!  One positive thing is that the new Emacs hasn't
fallen over.  ;-)

My 8% (approximate) I measured by scrolling through xdisp.c, displaying
each window's worth on the way.  Before repeating this timing, it's
necessary to insert a character at BOB then undo the insertion, so as to
erase the face and other properties throughout the buffer.

Perhaps you might be able to adapt this exercise into your branch.  At
any rate, I'd be interested if you could compare the timings on your
machine between old and new Emacs versions.

The code to run this follows.  Do M-: (time-scroll) to start it.

(defmacro time-it (&rest forms)
  "Time the running of a sequence of forms using `float-time'.
Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
  `(let ((start (float-time)))
    ,@forms
    (- (float-time) start)))

(defun time-scroll (&optional arg)
  (interactive "P")
  (message "%s"
           (time-it
            (condition-case nil
                (while t
                  (if arg (scroll-down) (scroll-up))
                  (sit-for 0))
              (error nil)))))

-- 
Alan Mackenzie (Nuremberg, Germany).