bug#25706: 26.0.50; Slow C file fontification

[Mattias Engdegård]

2 dec. 2020 kl. 11.15 skrev Alan Mackenzie <acm@muc.de>:

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

Thanks, it does indeed speed things up in various synthetic tests as well. You 
are right that there still seems to be at least a quadratic term left.

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

Please bear with my lack of understanding of how this works, but what I meant 
is that a preprocessor line neither affects nor is affected by the context, so 
until something other than such lines (and comments) are found in the region 
being fontified, there should be no need to determine the context in the first 
place.

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

There is optimism then! Some of the files from the Linux tree mentioned by 
Ravine Var are also good to try, such as
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_sh_mask.h