bug#25706: 26.0.50; Slow C file fontification

[Alan Mackenzie <acm@muc.de>]

Hello, Mattias.

On Tue, Dec 01, 2020 at 15:07:02 +0100, Mattias Engdegård wrote:
> 1 dec. 2020 kl. 13.57 skrev Alan Mackenzie <acm@muc.de>:

> > Just something I threw together a few years ago, and use regularly on
> > xdisp.c to check nothing's gone seriously slow/see how well my latest
> > optimisation has worked.

> Thank you, good, I just wanted to know that we are measuring the same thing!

> > How much time does this regexp change save on a "normal" file, such as
> > src/xdisp.c?

> Not much, but clearly measurable -- about 1.5 % (scrolling benchmark).

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

> What can be done for big files that mainly consist of preprocessor
> definitions? 

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

The cache would look something like (P . St) meaning P is the position of
the highest brace before St.  P nil would mean there was no opening brace
at all before St.

So any backward search for a { starting between P and St could just
return P, any search starting after St. would only need to search back to
St, and so on.  It's rather messy and easy not to get right first time,
but it could make a tremendous difference to these crazy include files.

I put in a cache like that for macros after somebody complained about the
sluggishness in his file (which was basically a single 4,000 line macro).

-- 
Alan Mackenzie (Nuremberg, Germany).