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

[Gemini Lasswell <gazally@runbox.com>]

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?

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