Hi, I was going to try it, but I just noticed it's only been commited in the windows-21.4 branch, might I ask why I can't benefit from it in the default branch :) ? Stef, who _has_ to work with that TraverseSchema.java file :( On Tue, Sep 10, 2002 at 07:45:29PM -0700, Andy Piper wrote: -- # Stef Epardaud, # Teachers have potentially more power than military, # Java Defeater # the former can teach us how to not need the latter. # Earth # Lunatech Research, # Solar System # soon we'll quit researching and start finding...

Andy> You can ask Stephen, Because the patch is broken. I've already identified a bug and a suspicious regression in 21.4.9 Windows [3]. make check is broken. That's fixed in my workspace; all the failed tests were due to not conditioning on the syntax-table feature, as you would expect. But it needed to be checked. Based on inspecting the patch, I thought maybe "\\<" in regexps broke too, but it tests OK. Writing up the test case for this also turned up a bug in the regexp "\\b" (which should be treated the same as "\\<\\|\\>" but isn't). That bug is present in vanilla 21.4, too. I've got a couple more unexplained regressions to check, and a bunch of code cleanups I want to do since the new bug makes it certain that I'll be looking at that code in the near future. Then I'll commit to the 21.4 mainline. Andy> but the default branch and windows branch are virtually Andy> identical now. You shouldn't have any problems using the Andy> windows branch under UNIX. Agreed. Expect 6 benign syntax test failures in make check, everything else should be the same. In stock 21.4.9, (setq lookup-syntax-properties nil) may be enough. In TraverseSchema.java from Xerces (thank you very much for that, Stef!) that setq exhausts the speedups for me. In fact, a stock 21.4.9 build with all error-checking turned on indents reportSchemaError as fast as a 21.4.9 Windows [3] with all error-checking off! But the stock build is 6 times as slow with (setq lookup-syntax-properties t). YMMV. Andy sees more speedups with Windows [3] compared to the setq. -- 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

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

It sounds like I should I try this again. andy