On Jul 27, 2010, at 2:24 PM, Stefan Monnier wrote:
> 
> I don't know about remote uses (I don't use them very often other than
> through terminal emulators), but at least local redisplay is currently
> borderline too slow in many of my use cases.  Now I don't have much of
> a clue about where the time is spent (maybe it's not really in
> redisplay), but at least performance is still an issue.

I agree entirely, and yet many of the other editors that are doing similar 
things (by which I mean primarily syntax-aware highlighting of various 
stripes) seem to be faster (at that part) than emacs and yet rely more 
heavily on graphical toolkits and provided widgets for such features.   I 
don't think that we could just `switch' to such techniques for emacs, but it
might be interesting to see how much more we could lean on existing gui
efforts.  Basically, I'm guessing that those projects spend a lot of time on 
graphical performance, and wondering (blue-sky, again) if we mightn't be 
able to add some capability and also some performance by trying to make
more use of other people's efforts.  For (very rough) example, the 
conversation between Yamamoto Mitsuharu and Jan Djärv about using 
toolkit exposure/clipping handling rather than trying to add our own.

My feeling is that redisplay's slowness comes from complicated font-lock
operations and the like.   Are there any other known sources of slow local
redisplay?   

*Chad