There are some basic performance testcases in the test/tests/perf/ directory. "build perf" from the test directory will execute them. I'm not sure whether/how results are reported; it's been a long time since I looked at them.
There's also the XSLTMark suite (http://www.datapower.com/XSLTMark/). I've sometimes used that as a test load under a performance analyser to see where Xalan is spending its time. But as with any benchmark, how meaningful the results of these tests are depends on how much they resemble what you're actually trying to do with the language. Performance issues for styling the maintainance manual for a 747 (thousands of pages of documentation) are likely to be very different than those for transcoding SOAP messages on a heavily loaded server, and the long-term answer may be differently-tuned processors for different problem domains. Performance versus completeness/correctness is an ongoing battle. For example, the recent changes I made to allow Xalan to process larger documents cost us a significant chunk of performance; I've since checked in some changes that bring us back into a more reasonable domain, though I still think we can do better. And we know there are some memory management opportunities.
