CC MODE Version 5 Documentation. Node: Performance Issues

PREV Syntactic Symbols UP Top NEXT Frequently Asked Questions

Chapter 8: 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. Such pathological code[1] can cause CC Mode 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 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 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 construct[2] 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 might want to set the variable defun-prompt-regexp to something reasonable [3], however that ``something reasonable'' is difficult to define, so CC Mode 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. CC Mode 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[4]. 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 CC Mode when working in files containing large amounts of C preprocessor macros. This is because Emacs cannot skip backwards over these lines as quickly as it can comment.

Previous versions of CC Mode 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[5]. CC Mode 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 CC Mode, 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 CC Mode distribution, but is completely unsupported. As mentioned previous, CC Mode always trades speed for accuracy, 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 accurancy for speed. 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.

[1] such as the output of lex(1)!

[2] e.g. a function in C, or outermost class definition in C++ or Java.

[3] Note that this variable is only defined in Emacs 19.

[4] This has been observed in Emacs 19.34 and XEmacs 19.15.

[5] It is hard to distinguish them from top-level declarations.

PREV Syntactic Symbols UP Top NEXT Frequently Asked Questions