From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: The current state of the comment-cache branch
Date: Wed, 28 Dec 2016 08:37:38 +0000 [thread overview]
Message-ID: <20161228083738.GA2304@acm.fritz.box> (raw)
In-Reply-To: <jwvtw9s57o7.fsf-monnier+gmane.emacs.devel@gnu.org>
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).
next prev parent reply other threads:[~2016-12-28 8:37 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-23 21:50 The current state of the comment-cache branch Alan Mackenzie
2016-12-24 1:32 ` Stefan Monnier
2016-12-24 9:07 ` Alan Mackenzie
2016-12-24 1:33 ` Stefan Monnier
2016-12-24 8:40 ` Alan Mackenzie
2016-12-24 20:56 ` Stephen Leake
2016-12-25 15:47 ` Stefan Monnier
2016-12-25 20:41 ` Richard Stallman
2016-12-24 8:02 ` Eli Zaretskii
2016-12-24 8:30 ` Alan Mackenzie
2016-12-24 8:55 ` Eli Zaretskii
2016-12-24 9:42 ` Alan Mackenzie
2016-12-24 11:11 ` Elias Mårtenson
2016-12-24 11:36 ` Alan Mackenzie
2016-12-24 12:00 ` Eli Zaretskii
2016-12-24 21:48 ` Andreas Röhler
[not found] ` <CADtN0W+7zHzuoWFrzs6MuonUM74D_dC+yh10rSk+r0nuxgeTBg@mail.gmail.com>
[not found] ` <CADtN0WJYXRg=oEBxn3UPjF6RFJG62nG4GpUFaphdkj9Egde_4Q@mail.gmail.com>
2016-12-24 12:21 ` Elias Mårtenson
2016-12-27 17:55 ` Alan Mackenzie
2016-12-28 15:36 ` Eli Zaretskii
2016-12-28 16:42 ` Alan Mackenzie
2016-12-28 16:45 ` Nikolaus Rath
2016-12-28 17:09 ` Eli Zaretskii
2016-12-28 23:58 ` Nikolaus Rath
2016-12-29 3:43 ` Eli Zaretskii
2016-12-29 16:56 ` Nikolaus Rath
2016-12-29 17:46 ` Eli Zaretskii
2016-12-29 19:44 ` Alan Mackenzie
2016-12-30 10:29 ` Andreas Röhler
2017-01-03 17:39 ` Stefan Monnier
2017-01-20 18:58 ` Andreas Röhler
2017-01-20 21:48 ` Stefan Monnier
2017-01-21 9:06 ` Andreas Röhler
2017-01-22 4:28 ` Stefan Monnier
2016-12-28 17:15 ` Stefan Monnier
2016-12-29 1:38 ` Richard Stallman
2016-12-29 2:15 ` Stefan Monnier
2016-12-24 12:27 ` Eli Zaretskii
2016-12-24 22:19 ` Paul Eggert
2016-12-25 16:07 ` Stefan Monnier
2016-12-25 16:30 ` Eli Zaretskii
2016-12-28 8:37 ` Alan Mackenzie [this message]
2016-12-28 17:02 ` Stefan Monnier
2016-12-28 17:10 ` Stefan Monnier
2016-12-27 16:40 ` Alan Mackenzie
2016-12-28 15:35 ` Eli Zaretskii
2016-12-28 16:35 ` Alan Mackenzie
2016-12-24 18:54 ` Richard Stallman
2016-12-27 16:11 ` Alan Mackenzie
2016-12-28 1:40 ` Dmitry Gutov
2016-12-28 7:54 ` Alan Mackenzie
2016-12-29 1:13 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161228083738.GA2304@acm.fritz.box \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).