C and its derivative languages are highly complex creatures. Often,
ambiguous code situations arise that require cc-mode
to scan
large portions of the buffer to determine syntactic context. Some
pathological code can cause cc-mode
to slow down considerably.
This section identifies some of the coding styles to watch out for, and
suggests some workarounds that you can use to improve performance.
Note that this is an area that will get a lot of attention in
cc-mode
version 5. The mode should end up being much faster, at
the expense of dropping Emacs 18 support, owing to the implementation of
syntactic analysis caching. This is the last release of cc-mode
that will be compatible with Emacs 18.
Because cc-mode
has to scan the buffer backwards from the current
insertion point, and because C's syntax is fairly difficult to parse in
the backwards direction, cc-mode
often tries to find the nearest
position higher up in the buffer from which to begin a forward scan.
The farther this position is from the current insertion point, the
slower the mode gets. Some coding styles can even force cc-mode
to scan from the beginning of the buffer!
One of the simplest things you can do to reduce scan time, is make sure
any brace that opens a top-level block construct always appears in the
leftmost column. This is actually an Emacs constraint, as embodied in
the beginning-of-defun
function which cc-mode
uses
heavily. If you insist on hanging top-level open braces on the right
side of the line, then you should set the variable
defun-prompt-regexp
to something reasonable (18), however that "something
reasonable" is difficult to define, so cc-mode
doesn't do it
for you.
You will probably notice pathological behavior from cc-mode
when
working in files containing large amounts of cpp macros. This is
because cc-mode
cannot quickly skip backwards over these lines,
which do not contribute to the syntactic calculations. You'll probably
also have problems if you are editing "K&R" C code, i.e. C code that
does not use function prototypes. This is because there are ambiguities
in the C syntax when K&R style argument lists are used, and
cc-mode
has to use a slower scan to determine what it's looking
at.
For the latter problem, I would suggest converting to ANSI style
protocols, and turning the variable c-recognize-knr-p
to
nil
(this is its default value for all modes).
For the former problem, you might want to investigate some of the
speed-ups provided for you in the file `cc-lobotomy.el', which
is part of the canonical cc-mode
distribution. As mentioned
previously, cc-mode
always trades accuracy for speed; however it is
recognized that sometimes you need speed and can sacrifice some accuracy
in indentation. The file `cc-lobotomy.el' contains hacks that
will "dumb down" cc-mode
in some specific ways, making that
trade-off of speed for accuracy. I won't go into details of its use
here; you should read the comments at the top of the file, and look at
the variable cc-lobotomy-pith-list
for details.
Go to the first, previous, next, last section, table of contents.