bug#25706: 26.0.50; Slow C file fontification

[Mattias Engdegård]

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

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

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?

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