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

Previous Next

Full log

View this message in rfc822 format

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

Hello, Mattias.

On Mon, Nov 30, 2020 at 17:53:04 +0100, Mattias Engdegård wrote:
> 30 nov. 2020 kl. 17.38 skrev Alan Mackenzie <acm <at> muc.de>:

> > Yes.  I've had a look at the file, and it's large and lacking in
> > braces.  There are functions in CC Mode which search backwards for
> > opening braces to establish context.  When there are none, the
> > search goes back to BOB.  Lots of these searches, not efficiently
> > cached, take a long time.

> > It's a problem with CC Mode, not with the source file.  It's a known
> > problem, and not easy to fix.

> Actually, it's the underscores!
> Demo: fill a file with the line pairs

> #define abc_defg_hij_klm__nop_qrst_uvw_xyz_w__ooa_cin_e__aoi__uynv(s) \
>  0

> repeated 1000 times, thus making it 2000 lines. Save as something.h. Slow!
> Now replace each underscore with a letter. Save. Fast!

> Fontifying the 2000 line file (with underscores) takes longer than the
> original 80000 line file.

Hey, wonderful!  I haven't tried it yet, but I did try this:
(i) Take the first 10% of the original 4MB file, and save it in a
  different file.
(ii) Fontify that file from top to bottom: according to EPL, 292s
(iii) Insert 9 new lines "{}" every 10% of that new file.
(iv) Fontify the amended file top to bottom: new time 98s.

That's a factor of 3 different.

> I started going through c-find-decl-spots and
> c-find-decl-prefix-search (together there are while statements nested
> 4 deep) but am not sure exactly where the trouble is. A regexp?
> Something syntax-char related (since '_' has symbol syntax, not word)?

> CC-mode in general thrashes the regexp cache; the miss rate is at 27 %
> for the original file, which is way too high. Enlarging the cache
> enough to eliminate misses helps, but not nearly enough.

So, you reckon replacing "\\(" by "\\(?:" wherever the first isn't
really needed would make a big difference?  Have I understood you right?
If so, I've got a big job ahead of me, going through all the regexps in
CC Mode doing the replacement, and fixing all the match_begininings and
match_ends, and so on, which depend on them.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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