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: The current state of the comment-cache branch Date: Tue, 27 Dec 2016 16:40:18 +0000 Message-ID: <20161227164017.GC2324@acm.fritz.box> References: <20161223215056.GA2771@acm.fritz.box> <83fuldzre1.fsf@gnu.org> <20161224083054.GA2212@acm.fritz.box> <83bmw1zoy8.fsf@gnu.org> <20161224094246.GD2212@acm.fritz.box> <8360m9zf4h.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 1482856891 8757 195.159.176.226 (27 Dec 2016 16:41:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Dec 2016 16:41:31 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 27 17:41:25 2016 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 1cLuoP-0000Y5-C1 for ged-emacs-devel@m.gmane.org; Tue, 27 Dec 2016 17:41:17 +0100 Original-Received: from localhost ([::1]:54927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLuoU-0008AD-A9 for ged-emacs-devel@m.gmane.org; Tue, 27 Dec 2016 11:41:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLunt-00089w-Dh for emacs-devel@gnu.org; Tue, 27 Dec 2016 11:40:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLunp-0005Ce-8O for emacs-devel@gnu.org; Tue, 27 Dec 2016 11:40:45 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:54010 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cLuno-0005CS-QP for emacs-devel@gnu.org; Tue, 27 Dec 2016 11:40:41 -0500 Original-Received: (qmail 87061 invoked by uid 3782); 27 Dec 2016 16:40:39 -0000 Original-Received: from acm.muc.de (p548C7014.dip0.t-ipconnect.de [84.140.112.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 27 Dec 2016 17:40:38 +0100 Original-Received: (qmail 3444 invoked by uid 1000); 27 Dec 2016 16:40:18 -0000 Content-Disposition: inline In-Reply-To: <8360m9zf4h.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.4 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:210846 Archived-At: Hello, Eli. On Sat, Dec 24, 2016 at 02:27:26PM +0200, Eli Zaretskii wrote: > > Date: Sat, 24 Dec 2016 09:42:46 +0000 > > From: Alan Mackenzie > > Cc: emacs-devel@gnu.org > > > Can you show similar timings with that variable set to nil? And in > > > particular in the use case reported by Paul back when bug#22884 was > > > filed? > > master: 101.939s 95.049s 103.546s > > (with open-paren-... nil) > Hmm... doesn't match my timings here. > With an optimized (-Og) build of Emacs 25.1.90, I get 42.844 with > open-paren-in-column-0-is-defun-start t and 62.234 nil. With the > unoptimized build of the current master, I get 193.922 and 1117.469, > respectively. The 193 sec result is marginally reasonable for an > unoptimized build, the 1117 sec result is IMO preposterous, and the > 6-fold slowdown is IMO too much to be explained just by the variable. If the buffer is large enough (were you using xdisp.c?) a large factor slowdown from using o-p-i-c-0-i-d-s seems inevitable. > Anyway, is your suggestion to adopt the code on that branch and set > open-paren-in-column-0-is-defun-start to nil? If we are not going to > set it to nil, then the speed advantage is IMO too small to justify > the changes. No. My suggestion is that open-paren-in-column-0-is-defun start ceases to play any role in syntax.c. Instead comments and strings will be scanned only in the forward direction, the results of these scan operations being cached in a text property. `back_comment' in syntax.c will be superseded by a new implementation which uses these text properties, and various other parts of Emacs will be amended to ensure these text properties stay consistent with the buffer and the current syntax table. All of this is implemented in the comment-cache branch, and completely removes the cause of all of these paren bugs. o-p-i-c-0-i-d-s would then have a role only in lisp.el in `beginning-of-defun-raw'. > Also, I wonder why do we need all these changes in syntax.c, when the > problem is AFAIK only with C mode and its derivatives. Are these > changes beneficial in any way to modes with non-C syntax? The changes are in syntax.c because this is where the fundamental cause of the problem lies. I don't believe it is possible to solve them in CC Mode. I don't know why the problem doesn't manifest itself in other modes. Perhaps other modes do less scanning of comments backwards (with `scan-sexps' with a negative count). > Thanks. > P.S. What does "hwm" stand for in literal-cache-hwm? As Paul suggested, "high water mark". It is perhaps not a very good name and could be changed. The allusion is to the highest point on a beach reached by the sea at high tide. This is marked as a line on some (English) maps under the abbreviation HWMOT, "high water mark, ordinary tide". -- Alan Mackenzie (Nuremberg, Germany).