bug#25706: 26.0.50; Slow C file fontification

["Mattias Engdegård" <mattiase@acm.org>]

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