From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Mon, 10 Dec 2018 19:35:57 +0000 Message-ID: <20181210193557.GE4188@ACM> References: <20181210180033.GC4188@ACM> <831s6p2qq1.fsf@gnu.org> <20181210182830.GD4188@ACM> <83zhtd1b0j.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544470791 22151 195.159.176.226 (10 Dec 2018 19:39:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2018 19:39:51 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 10 20:39:47 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWRP9-0005eq-Ci for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 20:39:47 +0100 Original-Received: from localhost ([::1]:34508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWRRF-0001vg-MY for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 14:41:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWRQa-0001va-HU for emacs-devel@gnu.org; Mon, 10 Dec 2018 14:41:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWRQX-0006Ue-8r for emacs-devel@gnu.org; Mon, 10 Dec 2018 14:41:16 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11126 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gWRQX-0006Ti-0h for emacs-devel@gnu.org; Mon, 10 Dec 2018 14:41:13 -0500 Original-Received: (qmail 79655 invoked by uid 3782); 10 Dec 2018 19:41:11 -0000 Original-Received: from acm.muc.de (p2E5D5AF9.dip0.t-ipconnect.de [46.93.90.249]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Dec 2018 20:41:10 +0100 Original-Received: (qmail 9547 invoked by uid 1000); 10 Dec 2018 19:35:57 -0000 Content-Disposition: inline In-Reply-To: <83zhtd1b0j.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231746 Archived-At: 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 > > > 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 # 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).