Re: cc-mode fontification feels random

[Eli Zaretskii]

> 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
> 
> I used pretty much your above test, except I started it at BOB of
> xdisp.c and used:
> 
>     M_: (dotimes (_ 700)
>           (message "%S" (benchmark-elapse (scroll-up) (sit-for 0)))
>           (sleep-for 0.05))
> 
> As you can see, the speed doesn't get noticeably worse as we go further
> into the file (the first few screenfuls were a bit faster, but after
> that it's a wash).

Can you produce a profile for that?

> Eli, do you see similar results?

Will Emacs 27.2 do?  If you must see results from an optimized build
of Emacs 28, I'll have to build one first.

> 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.

> 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?