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

Previous Next

Full log

View this message in rfc822 format

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: bug#25706: 26.0.50; Slow C file fontification
Date: Wed, 2 Dec 2020 16:06:43 +0100

2 dec. 2020 kl. 11.15 skrev Alan Mackenzie <acm <at> 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

Previous Next

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