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

[Alan Mackenzie <acm@muc.de>]

Hello, Gemini.

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

> Hi Alan,

> > Mainly because of EQ, the C macro corresponding to `eq'.  In master, EQ
> > just does a binary comparison between two Lisp_Objects, and that's it.
> > In scratch/accurate-warning-pos, should that binary comparison fail, EQ
> > additionally has to check the flag variable `symbols-with-pos-enabled'
> > to see whether it needs to do any additional comparisons.  Except while
> > byte compiling, it won't, but the check of that variable is what is
> > causing the slowdown.

> I'm having trouble accepting that this is the problem.

> When I hear a story about a C program, where adding an always failing
> check of a boolean variable to it causes it to run slower by 15% or 20%,
> then when I read the code I expect to find that variable check inside a
> really tight loop with only a few other instructions besides the
> variable check.

> But Fforward_word is significantly slower in your branch and I can't
> find any tight loops with an EQ in it.  exec_byte_code might fit that
> description, if you gave it a Lisp function with a loop that hammered on
> 'eq', but that doesn't describe fill-region-as-paragraph, which is 15%
> slower.  Could there be anything else causing a slowdown besides EQ?

In ..../src/lisp.h, we have:

    INLINE bool
    (NILP) (Lisp_Object x)
    {
      return lisp_h_NILP (x);
    }

, and earlier on in the file, we have

    #define lisp_h_NILP(x) EQ (x, Qnil).

So every NILP is substituted by EQ (x, Qnil).  There are a fair number
of NILPs in loops in Fforward_char and its subroutines.

> >> Another related question: this work is for warnings, but will it
> >> extend to having positions in backtraces?
> >
> > I hadn't actually got to thinking about that, but the answer is
> > proabably not, at least for now.  The .elc format for compiled functions
> > has a single entry for "each" symbol in its constant vector, and it
> > would be quite an exercise to augment that with symbols-with-position.
> >
> > Maybe for the future.

> Positions in error messages would be a major improvement as well.

Yes.  I wonder why this wasn't done long ago.

-- 
Alan Mackenzie (Nuremberg, Germany).