On 08 Feb 2002, Stephen J. Turnbull muttered drunkenly:
nix> In some (admittedly pathological) cases involving
K&R
nix> declarations and/or hanging-brace K&R brace style, it may
nix> have to chase all the way up to the top of the buffer and
nix> back down to work out what your indentation level is.
Yeah, but it doesn't seem to be an issue of pathology. It simply
seems to be a matter of buffer size. It seems that something is
_always_ chasing indentation or syntax over the whole buffer.
OK.
Did you look at the profile? One indentation causes 998 scan-lists
in
a 7000 line file! What with comment lines and the like, it sounds to
me like it's doing a scan-list for a very large proportion of the
lists in the file.
If I read the code correctly, it would need to do this if
c-recognize-knr-p was non-nil and your function headers were indented
(and maybe in other circumstances too; once, it needed to do it whenever
the K&R-style 1TBS was used, but I'm not sure if this is still the
case.)
nix> I don't think this will be fixable without truly
massive
nix> changes to cc-mode (which would probably cripple its
nix> indentation engine again).
That would be a bummer. But it would also be a bummer to find
ourselves forced to give up local syntax tables just because one
important application is wedded to an N^2 algorithm or something like
that.
Silly suggestion, but why not add an extra optional parameter to
scan-lists to turn off the use of local syntax tables for that call?
That way, pathological code like that in cc-mode that is found to be too
slow can have this new parameter set to t whenever it calls scan-lists
(in the hot spots where it does so pathologically often), and it can
speed up again without losing local syntax tables in more than one
place.
(Disclaimer: This may well not actually be possible: I haven't read the
code. If what I'm saying is garbage, please disregard it :) )
--
`It is to be proven that Linux Kernel is the most stable than MS Windows
that it uses less stable.' --- Bryan Parkoff being very comprehensible