From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Mon, 26 Nov 2018 17:07:07 -0800 Message-ID: <8736rnib0k.fsf@runbox.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1543280773 18463 195.159.176.226 (27 Nov 2018 01:06:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 01:06:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) Cc: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , Paul Eggert , michael_heerdegen@web.de, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 27 02:06:08 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 1gRRpI-0004hU-3w for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 02:06:08 +0100 Original-Received: from localhost ([::1]:39557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRRrO-0003he-Ia for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 20:08:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRRqm-0002Re-1j for emacs-devel@gnu.org; Mon, 26 Nov 2018 20:07:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRRqi-0005mw-VR for emacs-devel@gnu.org; Mon, 26 Nov 2018 20:07:40 -0500 Original-Received: from aibo.runbox.com ([91.220.196.211]:35766) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gRRqi-0005mE-LR; Mon, 26 Nov 2018 20:07:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=4hOp0gouFyvB9UFEciuPeRtniEO5WTH9+eZZaM4THm0=; b=A9km6lCFHoEcAFsVCX/lO4pxo0 znXI64CunIQLCjV6XHCdtOqrF+lgENhv6/EYxpAFn65DAXFup3zaxdac/s1gHgPbcUkyZFEX3Fk2I I7PC1m4fuDYVA9G+5mnN9towItKchxDyfk64Rtmv0/VwPhkiRrZ/8Tw2UxXUtMFXyIFirxYHvIBRz OHJmKkCF2og6R/YgLKaNbkZ1xARuRKQsVxgGxIeYQXKGNxKhO8AZhMEsCcLH/gtQawfwEB3zk7LcS sYT0AyMxW14xtFDf1hdlCsS2JHI5gYnlTlvYb+SQp1J7R/VnbKbk6VM/hdIZfqLTb+gbIfL8ebg6E 2jB/k47w==; Original-Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gRRqX-0007cM-K9; Tue, 27 Nov 2018 02:07:25 +0100 Original-Received: by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1gRRqI-0002Gj-TX; Tue, 27 Nov 2018 02:07:11 +0100 In-Reply-To: <20181126194249.GH4030@ACM> (Alan Mackenzie's message of "Mon, 26 Nov 2018 19:42:49 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.220.196.211 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:231424 Archived-At: 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? >> 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.