unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: scratch/accurate-warning-pos: next steps.
Date: Mon, 10 Dec 2018 19:35:57 +0000	[thread overview]
Message-ID: <20181210193557.GE4188@ACM> (raw)
In-Reply-To: <83zhtd1b0j.fsf@gnu.org>

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: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > 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	other threads:[~2018-12-10 19:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 18:00 scratch/accurate-warning-pos: next steps Alan Mackenzie
2018-12-10 18:15 ` Eli Zaretskii
2018-12-10 18:28   ` Alan Mackenzie
2018-12-10 18:39     ` Eli Zaretskii
2018-12-10 19:35       ` Alan Mackenzie [this message]
2018-12-10 20:06         ` Eli Zaretskii
2018-12-10 21:03           ` Alan Mackenzie
2018-12-11  6:41             ` Eli Zaretskii
2018-12-11 19:21               ` Stefan Monnier
2018-12-11 19:07             ` Stefan Monnier
2018-12-10 23:54 ` Paul Eggert
2018-12-11 11:34   ` Alan Mackenzie
2018-12-11 18:05     ` Paul Eggert
2018-12-11 19:20       ` Alan Mackenzie
2018-12-11 19:59         ` Paul Eggert
2018-12-11 20:51           ` Alan Mackenzie
2018-12-11 21:11             ` Stefan Monnier
2018-12-11 21:35               ` Alan Mackenzie
2018-12-11 22:58                 ` Stefan Monnier
2018-12-11 21:43             ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181210193557.GE4188@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).