Re: cc-mode fontification feels random

[Alan Mackenzie]

Hello, Eli.

On Fri, Jun 11, 2021 at 22:31:45 +0300, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  Alan Mackenzie <acm@muc.de>,
> >   rudalics@gmx.at,  rms@gnu.org,  emacs-devel@gnu.org
> > Date: Fri, 11 Jun 2021 14:42:31 -0400

[ .... ]

> > Would you say that this shows the slow behaviors that bother you?

> Of course.  100 msec for a single window-scroll is awfully slow.
> Especially since the display code itself takes only a fraction of
> that time.

> > E.g. there used to be a time where I found CC-mode unusably slow in
> > some cases, but these were typically while editing rather than while
> > scrolling (i.e. even simple buffer modifications incurred delays
> > measured in seconds).

> Yes, there are other use cases, but even this simple benchmark already
> shows that we have a serious problem, IMO.  Compare this with Emacs 23
> or with Emacs 28 in Fundamental mode.

Why do we have a problem?  If the time taken to fontify a window is less
than the auto-repeat time (the two times are close on a modern machine),
this is surely not a problem for somebody with such a machine.  It could
be a problem for somebody with a slower machine, or running an
unoptimised Emacs.

> > FWIW, I ran this same test with `sm-c-mode` (which should handle `xdisp.c`
> > about as well as CC-mode, but solves an easier problem since it doesn't
> > try to handle as much of C as CC-mode does (e.g. no support for K&R, no
> > highlighting of types), nor does it try to handle C++, Java, ...), and
> > most of the times for it are between 0.02 and 0.04.

> That is much better, but still too slow, IMO.  Think: it's the time
> that it takes us to fontify a single windowful, only a couple of
> dozens of lines.  Why does it take so long?

It does a very thorough job.  For example, one bug fix from many years
ago that I remember involved the fontification of foo in the following:

        ....
        int bar;
    } foo;

What face should foo have?  To answer that, you've got to go back over
the brace expression to see what's there.  If it's

    struct foo
    {
        int baz;
        ....

, we need font-lock-variable-name-face for foo.  On the other hand, if we
have

    typedef struct foo
    {
        int baz;
        ....

, we need font-lock-type-face.  Before the bug fix, foo just got variable
name face.  scan-lists backward over the brace expression takes time,
particularly for something the size of struct frame or even bigger.

-- 
Alan Mackenzie (Nuremberg, Germany).