Go to the first, previous, next, last section, table of contents.

# Performance Issues

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.