Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

Hello, Eli.

On Tue, Apr 07, 2020 at 22:22:43 +0300, Eli Zaretskii wrote:
> > From: Dmitry Gutov <address@hidden>
> > Date: Tue, 7 Apr 2020 18:04:13 +0300
> > Cc: address@hidden, address@hidden, address@hidden, address@hidden,
> >  address@hidden

> > Scenarios which are slow no matter what probably deserve a separate bug 
> > report each

> Agreed, let's get that ball rolling.

> > and are likely fixable without significant redesign.

> Unfortunately, I'm not as optimistic as you on that one.

> So here's the first bug report about a random slowness in CC Mode:

>   . visit src/w32.c on the emacs-27 branch and go to line 8747
>   . C-e DEL -- this deletes the last 'e' of "else"
>   . the following line gets immediately fontified as a function name
>   . type 'e' -- then watch how the fontification of the next line to
>     its original face takes almost 1 sec -- this is the problem

OK, I'm on Line 8759, where I've got:

  else
    cp->status = STATUS_READ_FAILED;

(I haven't updated for a few days.)  Is this the same place?

> FTR, this is in Emacs 27.0.90 built with -Og, but a -O2 compilation of
> Emacs 26.3 takes only slightly less time in this case.

Is this not jit-lock-context-time?

It takes 0.5s on my optimised build.  j-l-context-time is 0.5 here.
I'll admit I can't change the delay by changing j-l-c-t, but that might
be due to not reinitialising jit-lock properly.

However, first setting font-lock-support-mode to nil, then
reinitialising font-lock, deleting then reinserting that "e", the line
after the else _never_ gets its (lack of) face back.

> (I will file a formal bug report about this if Alan wants me to.)

No, it's fine like this!

-- 
Alan Mackenzie (Nuremberg, Germany).