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 19:42:49 +0000 Message-ID: <20181126194249.GH4030@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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1543261979 31208 195.159.176.226 (26 Nov 2018 19:52:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 19:52:59 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , Paul Eggert , monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 20:52:54 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 1gRMwA-0007yx-6g for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 20:52:54 +0100 Original-Received: from localhost ([::1]:38498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRMyG-0003lh-Fx for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 14:55:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRMpo-0004wu-Aj for emacs-devel@gnu.org; Mon, 26 Nov 2018 14:46:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRMpl-0007PY-3q for emacs-devel@gnu.org; Mon, 26 Nov 2018 14:46:20 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11488 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gRMpj-0007OW-4O for emacs-devel@gnu.org; Mon, 26 Nov 2018 14:46:15 -0500 Original-Received: (qmail 74380 invoked by uid 3782); 26 Nov 2018 19:46:13 -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 20:46:10 +0100 Original-Received: (qmail 30092 invoked by uid 1000); 26 Nov 2018 19:42:49 -0000 Content-Disposition: inline In-Reply-To: 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:231412 Archived-At: Hello, Clément. On Mon, Nov 26, 2018 at 14:18:36 -0500, Clément Pit-Claudel wrote: > On 26/11/2018 13.43, Alan Mackenzie wrote: > > 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? > This is a tricky question. Places where Emacs is too slow for my > taste, and that I wouldn't like to see become slower, include > indentation (which often requires many position-related operations, as > well as macro editing, and syntax highlighting. The pertinent position information doesn't exist at runtime. The only slowing down results from ..... > I do have one question: I understand why attaching positions to code > fragments make reading the code slower, but why does it make > interpreting it slower as well? 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. > 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. > Congrats on the had work, btw :) This would be a very useful feature > to have. Thanks! > Clément. -- Alan Mackenzie (Nuremberg, Germany).