Re: open large file with C code: is it realy should be so slow?

[Alan Mackenzie]

Hi, Richard!

On Mon, Jan 05, 2009 at 07:01:26PM -0500, Richard M Stallman wrote:
> I too find C mode painfully slow these days.  I wonder what changed to
> make it so much slower than it was.  Perhaps the only relevant change
> is that Font Lock is now enabled; I never used to enable it.  Even so,
> it must make a lot of users unhappy.

First of all, sorry.

Font lock consumes masses of cycles, yes.  Set
`font-lock-maximum-decoration' to 2; that might make it fast enough.

But no, not too many users seem too unhappy about it - at least, not
those who complain on address@hidden or emacs-devel.  Or, more
accurately, most complaints received have been because of specific
pessimisations which only manifest themselves in peculiar files (as in
the current thread) or in very big files.  These are relatively easy to
fix.

What speed of processor have you got?  With my 1.2 GHz Athlon, there is
a brief pause (~ 1 second) every now and then, while caches get checked
(not cheques getting cashed), and suchlike.  When I type, sometimes the
display is quite a few characters behind the keyboard.  But pauses like
that don't bother me too much; I just carry on typing, subconsciously
confident that Emacs will cache up soon enough.  But that's just me.

>From the tone of your post, I'm guessing that you're generally irritated
by sluggishness in C Mode rather because of any specific long wait.
There is at least one "peculiar" file in emacs, .../src/lisp.h in which C
Mode is sluggish locating BODs because of the number of #defines in it -
that shows up if you do C-x 4 a at its EOF.  But is there anything in
particular you've noticed which is particularly painful?

I'd guess that C Mode slowed down quite a lot in CC Mode 5.30, when the
font locking was taken into CC Mode, with the default decoration level
(3), prioritising accuracy over speed.  Since then, I've added a bit of
scanning to set syntax-table text properties so that the following sort
of stuff doesn't foul up parse-partial-sexp:

    #define LBRACE {
    #error unbalanced single quotes can't be ruled out.

K&R style declarations (more precisely, having to check for them) causes
quite a slow down.  They're never(?) used in modern C code, so maybe we
could flush them from .../src/*.[ch] and make K&R parsing an option.

-- 
Alan Mackenzie (Nuremberg, Germany).