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: Solid progress: the branch now bootstraps. Date: Tue, 27 Nov 2018 01:45:02 +0000 Message-ID: <20181127014502.GA4732@ACM> References: <20181125193050.GH27152@ACM> <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> <20181125212920.GK27152@ACM> <60ac9dfc-b540-89f9-68ea-ec7cceaa8511@cs.ucla.edu> <83in0kijz0.fsf@gnu.org> <9e216e61-7d95-94f0-cbee-593b4f32ced2@cs.ucla.edu> <20181126184359.GG4030@ACM> <20181126194249.GH4030@ACM> <8736rnib0k.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543283192 15617 195.159.176.226 (27 Nov 2018 01:46:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 01:46:32 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Paul Eggert , michael_heerdegen@web.de, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, Eli Zaretskii To: Gemini Lasswell Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 27 02:46:27 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 1gRSSJ-0003yp-2S for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 02:46:27 +0100 Original-Received: from localhost ([::1]:39652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRSUP-0002o5-Hy for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 20:48:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRSUJ-0002o0-JW for emacs-devel@gnu.org; Mon, 26 Nov 2018 20:48:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRSUG-0005IW-Pe for emacs-devel@gnu.org; Mon, 26 Nov 2018 20:48:31 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:55361 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gRSUG-0005IJ-FO for emacs-devel@gnu.org; Mon, 26 Nov 2018 20:48:28 -0500 Original-Received: (qmail 25006 invoked by uid 3782); 27 Nov 2018 01:48:27 -0000 Original-Received: from acm.muc.de (p2E5D5CCE.dip0.t-ipconnect.de [46.93.92.206]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 27 Nov 2018 02:48:25 +0100 Original-Received: (qmail 4744 invoked by uid 1000); 27 Nov 2018 01:45:02 -0000 Content-Disposition: inline In-Reply-To: <8736rnib0k.fsf@runbox.com> 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:231427 Archived-At: Hello, Gemini. On Mon, Nov 26, 2018 at 17:07:07 -0800, Gemini Lasswell wrote: > Alan Mackenzie writes: > Hi Alan, > > 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. > I'm having trouble accepting that this is the problem. > When I hear a story about a C program, where adding an always failing > check of a boolean variable to it causes it to run slower by 15% or 20%, > then when I read the code I expect to find that variable check inside a > really tight loop with only a few other instructions besides the > variable check. > But Fforward_word is significantly slower in your branch and I can't > find any tight loops with an EQ in it. exec_byte_code might fit that > description, if you gave it a Lisp function with a loop that hammered on > 'eq', but that doesn't describe fill-region-as-paragraph, which is 15% > slower. Could there be anything else causing a slowdown besides EQ? In ..../src/lisp.h, we have: INLINE bool (NILP) (Lisp_Object x) { return lisp_h_NILP (x); } , and earlier on in the file, we have #define lisp_h_NILP(x) EQ (x, Qnil). So every NILP is substituted by EQ (x, Qnil). There are a fair number of NILPs in loops in Fforward_char and its subroutines. > >> 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. > Positions in error messages would be a major improvement as well. Yes. I wonder why this wasn't done long ago. -- Alan Mackenzie (Nuremberg, Germany).