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

[Alan Mackenzie <acm@muc.de>]

Hello, Clément.

On Mon, Nov 26, 2018 at 14:18:36 -0500, Clément Pit-Claudel wrote:
> On 26/11/2018 13.43, Alan Mackenzie wrote:
> > This may be significant, but is it really important?  Most of the
> > time, Emacs is waiting for the next key depression anyway.  If a
> > batch like operation takes 11.5 minutes rather than 10 minutes, who
> > would really notice?  Similarly if an instantaneous operation, like
> > filling a paragraph increases by 15%, would anybody care?  It is
> > surely only those interactive operations which are sluggish which
> > might become more so, where the slowdown would be important.  How
> > many of these really exist in Emacs?

> This is a tricky question. Places where Emacs is too slow for my
> taste, and that I wouldn't like to see become slower, include
> indentation (which often requires many position-related operations, as
> well as macro editing, and syntax highlighting.

The pertinent position information doesn't exist at runtime.  The only
slowing down results from .....

> I do have one question: I understand why attaching positions to code
> fragments make reading the code slower, but why does it make
> interpreting it slower as well?

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.

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

> Congrats on the had work, btw :) This would be a very useful feature
> to have.

Thanks!

> Clément.

-- 
Alan Mackenzie (Nuremberg, Germany).