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

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Mon, Nov 26, 2018 at 09:43:46 -0800, Paul Eggert wrote:
> On 11/25/18 7:41 PM, Eli Zaretskii wrote:
> >> we could have a separate interpreter used only by the byte compiler.
> > I don't think I like this idea: it will be a maintenance burden to
> > maintain two interpreters, and we will have subtle long-lived bugs.

> Yes, the only way it's plausible is if we have just one source-code 
> instance of the interpreter, parameterized by whether it's doing things 
> the slower (byte-compiler-oriented) way or the faster (current) way, and 
> then partially evaluate the interpreter for the two cases.

I think you're going to be using the symbols-with-position approach, but
instead of evaluating symbols-with-pos-enabled on each instance of EQ,
NILP, and SYMBOLP, you're going to evaluate it just once, and branch to
the appropriate version of the interpreter for that case.

If you're not thinking of using the symbols-with-position approach, I
earnestly urge you to read the thread "Thoughts on getting correct line
numbers in the byte compiler's warning messages", which began here on
2018-11-01.  It might well persuade you.

> In that case the source code should be not much more complicated than
> scratch/accurate-warning-pos, and the number of subtle long-lived bugs
> should be about the same as scratch/accurate-warning-pos has now.

It will be more complicated, but not by an order of magnitude, perhaps.

> As I said, this approach is not for the fainthearted.

You're not kidding, there.

> But it should fix the significant performance problems in
> scratch/accurate-warning-pos.

The slowdown seems to be chrystallising out at 20 - 25% while byte
compiling, and 5 - 20% otherwise.

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?

As a data point, my 1.5 year old machine is about 150% faster (per core)
than its predecessor.

-- 
Alan Mackenzie (Nuremberg, Germany).