Re: fontlock-speed

On Fri, 08 Feb 2002, Hrvoje Niksic stipulated: > The reason for this is that I've encountered the font-lock/indentation > slowness myself, and complained about it. The maintainer of the > syntax code asked me to provide an example, which is when I found that > I couldn't repeat the extreme slowness using `xemacs -vanilla', or > after firing up any new XEmacs. If you have a repeatable case for > slowness, please provide it. I ran into a case of gutter-related hyperslowness a while back, the problem being that *everything* triggered a gutter redraw, and that window_changed was being set by things like every single mouse movement. It went away when I stopped being stupid and activating lazy-lock and lazy-shot at the same time (thick typo, I was trying to use lazy-shot alone). Even so, on the off-chance that this might be useful, here are some half-digested notes on the symptoms (and other random things I noticed at the same time): lazy-lock ocnditionalizes on `frame-modified-tick' --- but repainting the gutters increments this variable; so whenever the idle-hook fires, lazy-lock kicks up, changes the window (even if it's done nothing visible, especially in minibuffers), and the gutters promptly get repainted --- which increments frame-modified-hook again, so the next time it kicks up it'll hit that again! (Why does a window change trigger a gutter repaint anyway? windows != gutters...) Ancillary wonders: pgup triggers a gutter redisplay, but scrolling up doesn't, even if scroll-in-place is not in use. Popping up the minibuffer triggers a gutter_changed (by what, pray? I have no toolbars active or anything.) Disclaimer: none of this may apply with a sane configuration. This hasn't been checked much. This may make no sense. This is half-digested notes to myself. :) -- `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