Re: No syntax text properties!

Stef> aha, lemme try that ... WOW! ok, in my code it's also as Stef> fast as 21.4.9 Windows [3], both with error checking (right, Stef> now let's remove this error checking now ;) I finally got around to instrumenting update_syntax_cache. The experiment in question is start xemacs -vanilla, find-file TraverseSchema.java, go to line 8942, column 45, (setq lookup-syntax-properties t), and do newline-and-indent. In the first case, fontification is off (by accident, the file is 422387 bytes and my font-lock-maximum-size is 256000). In the second, fontification was first forced with font-lock-fontify-buffer. Look at this, with no fontification extents in the buffer: Syntax cache stats: updates 42000000, inits 1416, misses 1908, min length 1, max length 422394, mean length 413062.0, mean length on miss 294696.1 and this, with fontification (factor of 6 performance hit): Syntax cache stats: updates 42000000, inits 1416, misses 1838143, min length 1, max length 6048, mean length 159.8, mean length on miss 18.9 Note the number of updates (= actual call to update_syntax_cache): Deleting the whitespace (to return the file to its original state) costs another 6,000,000 updates. Yikes! Finally, although it's much slower (maybe another factor of 5? didn't time it) even than the with-previous-fontification experiment above, next-single-property-change (instead of next-extent-change) in setting up the cache reduces cache misses to _one_ except for those due to "buffer switches" ("inits" in the statistics). These stats are with prior fontification: Syntax cache stats: updates 43000000, inits 1602, misses 1603, min length 1, max length 422394, mean length 422387.1, mean length on miss 407325.4 But we should be able to get rid of nearly all of those inits, since there actually aren't _any_ buffer switches relevant to this experiment. What is happening is that Matt's code invalidates the cache on practically any "major" function call! (No, I have no idea why the number of updates is greater with next-single-property-change than next-extent-change.) I think I see how to do this. Speeding up next/previous-single-property-change is an obvious target, but I don't see how to do it offhand. That will have to wait. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py