CC Mode with font-lock-maximum-decoration 2 [Was Major modes using `widen' is a good, even essential, programming practice.]

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Aug 08, 2022 at 14:39:56 +0300, Eli Zaretskii wrote:
> > Date: Mon, 8 Aug 2022 09:58:29 +0000
> > Cc: gregory@heytings.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > > I don't know what makes it [CC Mode with
> > > font-lock-maximum-decoration 2] slow, but it feels sluggish in even
> > > the simplest editing operations, and font-lock updates are slow as
> > > well.

I don't think that's entirely true.  I've just measured the font-locking
time, and (let's call it) CC Mode/2 fontifies at 72% the speed of Emacs
Lisp Mode.  I don't think it's reasonable to expect more than that, given
that C is more complicated than Lisp.

I think it more likely that the before/after-change-functions in CC
Mode/2 are excessive, and making it look like fontification is slow.

For this measurement, I started with subr.el, and appended copies of it
to itself, then took functions off the end, to make it the same size as
xdisp.c.  xdisp.c is 1209233 bytes, my .el buffer was 1209371 bytes.

I used M-: (benchmark-run 1 (time-scroll-b)) on each buffer, with:

    (defun time-scroll-b (&optional arg)    ; For use in `benchmark-run'.
      (condition-case nil
          (while t
            (if arg (scroll-down) (scroll-up))
            (sit-for 0))
        (error nil)))

..  The exact results were:
(xdisp.c): (5.7370774540000005 9 0.7672129740000013)
(elisp):   (4.1201735589999995 5 0.42918214299999846).

This was, of course, on an optimised build on GNU/Linux using the Linux
console, both measurements starting at BOB, having typed and deleted a
character to erase existing font-locking.

> > How about us opening a bug report for CC Mode's speed with
> > font-lock-maximum-decoration = 2?

> Consider it open.  I'm sure I complained about this more than once
> already, and yet here we are.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).