Re: why does M-w (kill-ring-save) hurt so bad?

Georg> M-x font-lock-fontify-buffer (wait and watch the bloat) Known, and we have worked on it. But we don't know what causes it (in detail). Can you post your Installation? I'm particularly interested in (a) the version (if < 21.4.10, you're missing the most important patch since the initial release) and (b) Mule and error-checking settings, but give me the whole thing, it's small. Georg> Easily dismissed as a "don't do that". For about 5 years too long now we've been dismissing it and spending time on caching and lazylocking and foolery. I don't know why fontlocking assembler would take so long, but I can tell you something about Java: the typical Java program is class-per-file, ie, you only have one defun per file. This means that comment parsing takes bloody forever, because of the "back up 1000 bytes at a time looking for an open defun outside of a comment" algorithm we use. With processors running at 20X bus speed, I see no excuse any more for not doing a full syntactic parse of the buffer, laying down extents as we go. Yes, every time. The fontlocker should be able to beat the IO to the end of the buffer. (Well, not quite. ;-) When I profiled `indent-according-to-mode' a while back on a line 95% of the way through a 400k Java file[1], it was calling a certain subroutine 40 _million_ times (moving the "shall I actually do any work" test out of the called function into the caller in 21.4.10 cut the time by about 97% in that case---still too slow though). Surely a one-pass full parse can't be slower than that kind of thing! Then once we've got that, we can figure ways of "locking down" most of the preparsed extents. Eg, a change should not invalidate any syntactic structure that ends before or starts after the changed region. Any takers? Georg> Except that GNU Emacs has no trouble with it. Yeah, I don't understand that. Matt Tucker did some benchmarking, found GNU Emacs _marginally_ faster, and switched some stuff (back) to GNU Emacs algorithms. It would be really nice if somebody would take a look at that, too. Footnotes: [1] TraverseSchema.java from the Xerces distribution. It's a single class. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.