unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* A possible way for CC Mode to resolve its sluggishness
@ 2019-04-26 19:30 Alan Mackenzie
  2019-04-26 19:53 ` Eli Zaretskii
  2019-04-27  2:10 ` Stefan Monnier
  0 siblings, 2 replies; 10+ messages in thread
From: Alan Mackenzie @ 2019-04-26 19:30 UTC (permalink / raw)
  To: emacs-devel, bug-cc-mode

Hello Emacs, CC Mode.

In the last few years there's been a continual stream of posts
complaining (always good naturedly) about the sluggishness of CC Mode
during extended buffer change operations, and sometimes even with single
operations (such as typing into a C++ raw string).

Recently, Zhang Haijun, noted that iedit-mode (a mode that performs
simultaneous edits on, say, all occurrences of a variable name
throughout a buffer) didn't work well in C++ Mode, because of the time
taken by its after-change-functions.

The problem is that CC Mode's before/after-change-functions are very
general, and scan the buffer looking for situations which only arise
sporadically.  Things like an open string getting closed, or a > being
inserted which needs to be checked for a template delimiter.  However,
these expensive checks are performed for _every_ buffer change.  Even
doing something like inserting a letter or a digit causes the full range
of tests to be performed.  This is not good.

To improve this, I propose that at a buffer change, simple fast
plausibility checks be performed before the change-functions get run,
and only where something complicated is afoot should (selected)
change-functions be run.  For example, inserting a letter or digit will
only rarely be complicated, inserting a brace or semicolon will usually
be so.

Now to the detailed proposal:
(i) A CC Mode buffer will be partitioned into @dfn{syntactic cells}.
These will be things like a section of code, a comment, a string, a raw
string, a CPP construct ....  Possibly even comment delimiters would
have their own cells.

(ii) Syntactic cells will be implemented by a text property, c-syntax,
whose value will indicate the type of the cell, and possibly an
identifier for it.  Neighbouring cells will always have distinct
c-syntax values.

(iii) On a buffer change which removes characters, we check for things
like:
  o - (beg end) straddling or touching cell borders;
  o - "structural" characters in (beg end) (say a brace or semicolon);
  o - "boundary" characters in (beg end) (say a comment or string
  delimiter);
  o - things happening with backslashes, etc.
If any of these things is true, we run the before-change-functions (or a
subset of them).  This will only happen every now and then.  When it
does, we will likely adjust the syntactic cells.

(iv) When a buffer change inserts characters, we check basically the
same things as in (iii) and if needed, run (a subset of) the
after-change-functions.  This also will only happen now and then, and
will like necessitate adjustment of the syntactic cells.

It will probably be possible to eliminate one or more existing CC Mode
structural caches - the speed of text property search (compared with
parse-partial-sexp from a cached "safe" position) will make this
possible.

Thoughts?

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-04-29 12:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-26 19:30 A possible way for CC Mode to resolve its sluggishness Alan Mackenzie
2019-04-26 19:53 ` Eli Zaretskii
2019-04-26 20:11   ` Alan Mackenzie
2019-04-27  2:10 ` Stefan Monnier
2019-04-27  3:34   ` Óscar Fuentes
2019-04-27 13:57   ` Alan Mackenzie
2019-04-28 17:32     ` Stephen Leake
2019-04-29  1:46     ` Stefan Monnier
2019-04-29  9:23       ` Alan Mackenzie
2019-04-29 12:19         ` Stefan Monnier

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).