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

Previous Next

Packages: emacs, cc-mode;

Reported by: Sujith <m.sujith <at> gmail.com>

Date: Mon, 13 Feb 2017 18:41:01 UTC

Severity: normal

Tags: moreinfo

Found in version 26.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

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: Tue, 8 Dec 2020 20:32:12 +0100
Hello Alan,

8 dec. 2020 kl. 19.42 skrev Alan Mackenzie <acm <at> muc.de>:
>   That's 133,000 lines, give or take.  Even our largest file,
> src/xdisp.c is only 36,000 lines.  I don't understand how a file
> describing hardware can come to anything like 133k lines.  It must be
> soul destroying to have to write a driver based on a file like this.
> That file was put together by AMD, and I suspect they didn't take all
> that much care to make it usable.

Those files are likely not hand-written but generated from a hardware description language where device registers are declared in more comfortable ways, and often are part of or at least have tie-ins to VLSI synthesis tools.

Nevertheless, there are quite big files that are crafted by hand, and in any case users need to look at them sooner or later in an editor anyway (hence the bug report), so the speed-up job here is essential and benefits everyone.

> There's one thing which still puzzles me.  In osprey_reg....h, when
> scrolling through it (e.g. with (time-scroll)), it stutters markedly at
> around 13% of the way through.

Tried applying my regexp patch? It should reduce the pain, which may indicate that the stuttering is caused by severe regexp backtracking effects.

> Anyhow, please try out the (?)final version of my patch before I commit
> it and close the bug.  It should apply cleanly to the master branch.  I
> might well split it into three changes, two small, one large, since
> there are, in a sense three distinct fixes there.

Thank you very much, I'll take a look, and as promised I'll put together a more detailed guide to what I think could be done about some of the regexps.






This bug report was last modified 4 years and 213 days ago.

Previous Next


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