C and its derivative languages are highly complex creatures. Often, ambiguous code situations arise that require @ccmode{} to scan large portions of the buffer to determine syntactic context. Such pathological code(30) can cause @ccmode{} to perform fairly badly. This section identifies some of the coding styles to watch out for, and suggests some workarounds that you can use to improve performance.
Because @ccmode{} 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, @ccmode{} 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 @ccmode{} to scan from the beginning of the buffer for every line of code!
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 @ccmode{} 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 (31), however that "something
reasonable" is difficult to define, so @ccmode{} doesn't do it
for you.
A special note about defun-prompt-regexp
in Java mode: while much
of the early sample Java code seems to encourage a style where the brace
that opens a class is hung on the right side of the line, this is not a
good style to pursue in Emacs. @ccmode{} comes with a variable
c-Java-defun-prompt-regexp
which tries to define a regular
expression usable for this style, but there are problems with it. In
some cases it can cause beginning-of-defun
to hang(32). For this reason,
it is not used by default, but if you feel adventurous, you can set
defun-prompt-regexp
to it in your mode hook. In any event,
setting and rely on defun-prompt-regexp
will definitely slow
things down!
You will probably notice pathological behavior from @ccmode{} when working in files containing large amounts of cpp macros. This is because Emacs cannot be made to quickly skip backwards over these lines.
Previous versions of @ccmode{} had potential performance problems
when recognizing K&R style function argument declarations. This was
because there are ambiguities in the C syntax when K&R style argument
lists are used(33). @ccmode{} has adopted BOCM's convention for
limiting the search: it assumes that argdecls are indented at least one
space, and that the function headers are not indented at all. With
current versions of @ccmode{}, user customization of
c-recognize-knr-p
is deprecated. Just don't put argdecls in
column zero!
You might want to investigate the speed-ups contained in the
file `cc-lobotomy.el', which comes as part of the @ccmode{}
distribution, but is completely unsupported.
As mentioned previous, @ccmode{} 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" @ccmode{} 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.