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: Wed, 28 Dec 2016 08:37:38 +0000 Message-ID: <20161228083738.GA2304@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 1482914331 8663 195.159.176.226 (28 Dec 2016 08:38:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2016 08:38:51 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 28 09:38:47 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 1cM9kt-0000zY-PA for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 09:38:39 +0100 Original-Received: from localhost ([::1]:58246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cM9ky-0008JD-CD for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 03:38:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cM9kL-0008J5-0K for emacs-devel@gnu.org; Wed, 28 Dec 2016 03:38:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cM9kH-0007Rs-W6 for emacs-devel@gnu.org; Wed, 28 Dec 2016 03:38:05 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:25317 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cM9kH-0007RO-Jm for emacs-devel@gnu.org; Wed, 28 Dec 2016 03:38:01 -0500 Original-Received: (qmail 7904 invoked by uid 3782); 28 Dec 2016 08:37:59 -0000 Original-Received: from acm.muc.de (p548C6B77.dip0.t-ipconnect.de [84.140.107.119]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 28 Dec 2016 09:37:58 +0100 Original-Received: (qmail 3816 invoked by uid 1000); 28 Dec 2016 08:37:38 -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.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:210877 Archived-At: Hello, Stefan. Thanks for such a thorough summary of the issue. On Sun, Dec 25, 2016 at 11:07:46AM -0500, Stefan Monnier wrote: > > 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 actual cause of the problem is in syntax.c. > The core of the problem is calls to (forward-comment -1). More precisely, in CC Mode, what triggers the problem is usually scan-lists with a negative `count' argument. This calls back_comment, which is where the problem happens. > Both this comment-cache and my syntax-ppss patch attack this specific > operation only. This operation is currently implemented by trying to > skip comments "locally" by parsing backward, but when that fails, we use > parse-partial-sexp from point-min to find the matching opening of > a comment closer. > This expensive forward pass is not a problem in practice unless your buffer > is huge, or unless it happens many times within a single command. > These can happen in any major mode, basically. > It's only a historical accident if it seems to affect CC-mode more. > open-paren-in-column-0-is-defun-start is the current hack to try and > reduce the occurrence of this problem by only calling parse-partial-sexp > from the closest open-paren-in-column-0, which works fairly well in > practice for typical Elisp code as well as for typical C code (tho not > for all coding styles). > [ AFAIK open-paren-in-column-0-is-defun-start was specifically designed > for this (forward-comment -1) issue, but it is also used in > beginning-of-defun, although the two uses are completely independent and > of a different nature: the use in forward-comment is supposed to be only > an optimization, whereas the use in beginning-of-defun is meant to > really change the result. So beginning-of-defun is completely > irrelevant to and independent from this thread. ] > Also in the latest case where a major slow down showed up in CC-mode, > the problem was reversed: CC-mode had some special code for when > open-paren-in-column-0-is-defun-start is non-nil (can't remember what > it was for), which was the cause of the slow down, IIRC. Bug #22884. This isn't quite accurate. The slowdown happened when C Mode thought that the "(" in the comment was a BOD and in repeated scanning to point (which is typically harmless) was scanning many times over ~40k characters. > Both Alan's comment-cache and my syntax-ppss patch aim to replace the > open-paren-in-column-0-is-defun-start hack so as to completely eliminate > this pathological (forward-comment -1) case. Is your syntax-ppss patch at a state where it could be benchmarked and tested? If so, please say again where it is, or put it somewhere public. Dmitry is interested in it too. > Stefan -- Alan Mackenzie (Nuremberg, Germany).