[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/accurate-warning-pos: next steps.

From: Alan Mackenzie
Subject: Re: scratch/accurate-warning-pos: next steps.
Date: Mon, 10 Dec 2018 19:35:57 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Eli.

On Mon, Dec 10, 2018 at 20:39:56 +0200, Eli Zaretskii wrote:
> > Date: Mon, 10 Dec 2018 18:28:30 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > I don't think I understood when will this alternative interpreter be
> > > used, and when will the "primary" one be used.  Can you elaborate on
> > > that?

> > Yes.  The alternative interpreter would be used only for byte
> > compilation (and possibly other programs which want to use the symbols
> > with position mechanism), the primary one will be used at all other
> > times.

> Then how about invoking this alternative interpreter only if the prime
> interpreter detected a warning or error while byte-compiling?  You
> could invoke the alternative interpreter only on the form where the
> problem was detected, with the goal of "drilling down" to find the
> exact position of the problematic symbol(s).

That would mean starting the byte compilation with no position
information being gathered, and then when an warning occurs, aborting
the compilation and starting again from scratch with the position
information being gather and alternative interpreter being used.

The problem is, that we cannot use #<symbol nil at 666> in the normal
interpreter, since it is not EQ nil there.

> This would have the advantage of not only avoiding the slow-down in
> the "prime" interpreter, but also avoiding slowing down byte
> compilation of error-free sources.

This is an optimisation.

> Does this make sense?

I understand the idea, yes.  But given the timings I measured in the
existing scratch/accurate-warning-pos (IIRC, around 11% - 12% for an
actual compilation) and the fact that in the alternative interpreter,
the slowdown will be somewhat less (one fewer flag comparison per EQ,
NILP, ...., and we can drop the traditional alist of symbols and
positions which is running alongside the new symbols with position) it
may not be worth the extra complexity.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]