Re: cc-mode fontification feels random

[Eli Zaretskii <eliz@gnu.org>]

> Cc: acm@muc.de, rudalics@gmx.at, monnier@iro.umontreal.ca, rms@gnu.org,
>  emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Fri, 11 Jun 2021 11:28:18 -0700
> 
> >    0.015625
> >    0.03125
> >    0.015625
> >    0.046875
> >    0.09375
> >    0.0625
> >    0.015625
> >    0.03125
> >    0.015625
> >    0.03125
> >    0.015625
> >    0.03125
> >
> > You consider this to be adequate performance for a single
> > window-scroll?  (I don't have an optimized build of Emacs 28, but
> > there's no reason to believe it is faster; quite the opposite.)
> 
> native-comp?

No (it's Emacs 27).  But Alan already timed the native and non-native
versions in Emacs 28, and didn't find any tangible difference.  In
fact, the byte-compiled code was slightly faster.

> > 	- font-lock-fontify-region                                  157  65%
> > 	 - c-font-lock-fontify-region                               157  65%
> > 	  - font-lock-default-fontify-region                        146  60%
> > 	   - font-lock-fontify-keywords-region                      143  59%
> > 	    - c-font-lock-declarations                               97  40%
> > 	     - c-find-decl-spots                                     97  40%
> > 	      - #<compiled -0x1ffffffff94b65d0>                      73  30%
> > 	       - c-forward-decl-or-cast-1                            38  15%
> > 		- c-forward-type                                     22   9%
> > 		 - c-check-qualified-type                             7   2%
> >
> > We can stick our heads in the sand as much as we want, but facts are
> > stubborn things.
> 
> Hrm. That doesn't seem consistent with Alan's report that we spend a ton 
> of time doing work like deciding whether a brace occurs at top-level.

Maybe we should produce profiles on different systems and compare
them, so that we are sure the data is solid and repeatable?

Or maybe Alan was talking about Emacs 28, where something has changed
considerably?

> My question stands: what core facilities can we add to accelerate
> cc-mode's parsing here? There's got to be some efficiency we can
> gain here.

I don't think we have an answer to that.  Alan, do you have some
suggestions?

If we don't have anything we already figured out, I guess the answer
should be found by studying the code of the hot spots and looking for
optimization opportunities or algorithmic changes.