[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Advising in cc-awk.el and namespace

From: Stefan Monnier
Subject: Re: Advising in cc-awk.el and namespace
Date: Fri, 11 Jul 2003 13:35:36 -0400

>     load a large file (say, ..../emacs/src/keyboard.c) wait for jit-lock to
>     finish fontifying it in the background, then make a small change near the
>     beginning of this file, needlessly refontifying ~320kBytes consumes ~55%
>     of the CPU's power for 3½ minutes.
> Why does a small change near the beginning refontify the whole file?
> I suppose there are some small changes that might legitimately do so,
> but I would not expect most small changes to do so.  What's up?

Because in general, it might be necessary and font-lock does
not try to be clever here.

Basically syntactic-fontification (fontification of comments and string)
depends on the output of `syntax-ppss' and because font-lock-keyword
rules are order-dependent (they typically are only applied if there isn't
already some fontification at point, so that keywords aren't highlighted
inside strings), after redoing syntactic-fontification, keywords
fontification needs to be redone as well.

A change at pos N potentially changes the output of syntax-ppss for
all pos>N, so jit-lock just refontifies everything (in the background
with jit-lock-stealth-*).  Of course, in practice the output of
syntax-ppss is generally not changed for all pos>N but only for N<pos<M
(or sometimes it is changed for all pos>N but the change is marginal or
irrelevant and will not influence the result of font-locking), so we could
be more clever, but we would need to cache the parse-state-before-change
so we can compare it to the parse-state-after-change so we can stop when
they are equal again.  It might be worth the effort, but nobody has
bothered coding it up yet.  Turning off jit-lock-stealth-* is a simpler
workaround for the CPU-power-wasting problem.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]