bug#25706: 26.0.50; Slow C file fontification

[Alan Mackenzie <acm@muc.de>]

Hello, Mattias.

On Tue, Dec 01, 2020 at 19:59:04 +0100, Mattias Engdegård wrote:
> 1 dec. 2020 kl. 16.27 skrev Alan Mackenzie <acm@muc.de>:

> > Ah.  ;-)  Do you think the difference might be significantly more if I
> > were systematically to expunge "\\("s from CC Mode?

> No, probably not. It's just obvious low-hanging fruit; every little
> helps some. Doing so also makes the regexps a little less mystifying
> for the reader since the only capture groups left are those actually
> used. Finally, it removes or at least raises some hard limits that we
> had in the past (from regexp stack overflow).

OK.  That's a project for ASAP, but not, then, urgent.

> > Add in yet another cache (or fix the existing cache which is buggy)
> > for whatever it is that's searching backwards for braces.

> Are the bugs in the existing cache preventing it from making the cases
> under discussion faster?

I spent yesterday evening investigating the "CC Mode state cache", i.e.
the thing that keeps track of braces and open parens/brackets.  I found a
place where it was unnecessarily causing scanning from BOB, and fixed it
provisionally.  On doing a (time-scroll) on the entire monster buffer, it
saved ~25% of the run time.  There is definitely something else scanning
repeatedly from BOB - the screen scrolling was more sluggish near the end
of the buffer than half way through.

Here's that provisional patch, if you'd like to try it:



diff -r 863d08a1858a cc-engine.el
--- a/cc-engine.el	Thu Nov 26 11:27:52 2020 +0000
+++ b/cc-engine.el	Wed Dec 02 09:55:50 2020 +0000
@@ -3672,9 +3672,9 @@
 	    how-far 0))
      ((<= good-pos here)
       (setq strategy 'forward
-	    start-point (if changed-macro-start
-			    cache-pos
-			  (max good-pos cache-pos))
+	    start-point  ;; (if changed-macro-start  OLD STOUGH, 2020-12-01
+			 ;;    cache-pos
+			  (max good-pos cache-pos);; )
 	    how-far (- here start-point)))
      ((< (- good-pos here) (- here cache-pos)) ; FIXME!!! ; apply some sort of weighting.
       (setq strategy 'backward



> A naïve question: the files we are talking about are dominated by
> (mostly single-line) preprocessor directives whose fontification should
> be invariant of context (as long as they are not inside comments or
> strings, but that's not hard to find out). Why do we then spend time
> looking for context at all?

Because many situations are context dependent, particularly in C++ Mode.
That raises the possibility of not tracking context for these monster
files.h, but how would one distinguish between these different "types" of
CC Mode file?

> From profiling, it seems that about 30 % of the time is spent in
> c-determine-limit, called from c-fl-decl-start,
> c-font-lock-enclosing-decls and c-font-lock-cut-off-declarators (about
> 10 % each).

Yes.  c-determine-limit scans backwards over a buffer to find a position
that is around N non-string non-comment characters before point.

I put some instrumentation on it yesterday evening, and it is apparent
that it is getting called four times in succession from the same point
with N = 500, 1000, 1000, 1000.  This screams out for a simple cache,
which I intend to implement.  Also, maybe I should always call
c-determine-limit with the same N, and perhaps even cut N to 500 in all
cases.  Or something like that.  It is clear that a great deal of run
time could be saved, here.

Also, I intend to track down whatever the other thing is that is scanning
from the previous brace or BOB.  It may be possible to alter the handling
of these monster files from impossibly slow to somewhat sluggish.

-- 
Alan Mackenzie (Nuremberg, Germany).