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: Mon, 26 Nov 2018 18:43:59 +0000 Message-ID: <20181126184359.GG4030@ACM> References: <83muq7u9rk.fsf@gnu.org> <20181123130904.GA2916@ACM> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543257962 1678 195.159.176.226 (26 Nov 2018 18:46:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 18:46:02 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 19:45:58 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 1gRLtO-0000GV-0j for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 19:45:58 +0100 Original-Received: from localhost ([::1]:38193 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRLvU-00069Q-MQ for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 13:48:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRLup-00067D-NB for emacs-devel@gnu.org; Mon, 26 Nov 2018 13:47:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRLum-0007m7-Hm for emacs-devel@gnu.org; Mon, 26 Nov 2018 13:47:27 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:15249 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gRLum-0007ls-4O for emacs-devel@gnu.org; Mon, 26 Nov 2018 13:47:24 -0500 Original-Received: (qmail 48801 invoked by uid 3782); 26 Nov 2018 18:47:23 -0000 Original-Received: from acm.muc.de (p2E5D5CCE.dip0.t-ipconnect.de [46.93.92.206]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 26 Nov 2018 19:47:19 +0100 Original-Received: (qmail 29896 invoked by uid 1000); 26 Nov 2018 18:43:59 -0000 Content-Disposition: inline In-Reply-To: <9e216e61-7d95-94f0-cbee-593b4f32ced2@cs.ucla.edu> 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:231406 Archived-At: Hello, Paul. On Mon, Nov 26, 2018 at 09:43:46 -0800, Paul Eggert wrote: > On 11/25/18 7:41 PM, Eli Zaretskii wrote: > >> we could have a separate interpreter used only by the byte compiler. > > I don't think I like this idea: it will be a maintenance burden to > > maintain two interpreters, and we will have subtle long-lived bugs. > Yes, the only way it's plausible is if we have just one source-code > instance of the interpreter, parameterized by whether it's doing things > the slower (byte-compiler-oriented) way or the faster (current) way, and > then partially evaluate the interpreter for the two cases. I think you're going to be using the symbols-with-position approach, but instead of evaluating symbols-with-pos-enabled on each instance of EQ, NILP, and SYMBOLP, you're going to evaluate it just once, and branch to the appropriate version of the interpreter for that case. If you're not thinking of using the symbols-with-position approach, I earnestly urge you to read the thread "Thoughts on getting correct line numbers in the byte compiler's warning messages", which began here on 2018-11-01. It might well persuade you. > In that case the source code should be not much more complicated than > scratch/accurate-warning-pos, and the number of subtle long-lived bugs > should be about the same as scratch/accurate-warning-pos has now. It will be more complicated, but not by an order of magnitude, perhaps. > As I said, this approach is not for the fainthearted. You're not kidding, there. > But it should fix the significant performance problems in > scratch/accurate-warning-pos. The slowdown seems to be chrystallising out at 20 - 25% while byte compiling, and 5 - 20% otherwise. This may be significant, but is it really important? Most of the time, Emacs is waiting for the next key depression anyway. If a batch like operation takes 11.5 minutes rather than 10 minutes, who would really notice? Similarly if an instantaneous operation, like filling a paragraph increases by 15%, would anybody care? It is surely only those interactive operations which are sluggish which might become more so, where the slowdown would be important. How many of these really exist in Emacs? As a data point, my 1.5 year old machine is about 150% faster (per core) than its predecessor. -- Alan Mackenzie (Nuremberg, Germany).