GNU bug report logs - #25706
26.0.50; Slow C file fontification

Previous Next

Full log

Message #74 received at 25706 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 25706 <at> debbugs.gnu.org
Subject: Re: bug#25706: 26.0.50; Slow C file fontification
Date: Tue, 1 Dec 2020 19:59:04 +0100

1 dec. 2020 kl. 16.27 skrev Alan Mackenzie <acm <at> 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). 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.