Hi, I thought I should follow up on my announcement to take a closer look at XSLTMark. First the good news: it works. All open source java XSL processors I could get my hands on (Xalan, Xt, Saxon) work, too. We get the same correctness results like JDK 1.3.1 on linux.
The bad news: we are slower than JDK 1.3.1. Especially xalan seems to suffer from class and resource loading. So I'd like to propose a new caching scheme for our system class loader: beside just caching classes, it should cache the directories (i.e. packages) in classpath entries. That should reduce the cost of class/resource lookup from linear (scanning the classpath) to constant (single classpath entry) for most resources. So next time the class loader is looking for "a/b/c" it could do a cache lookup on "a/b", and get a List of classpath entries x,y, and z, in that order. Now it only needs to scan x,y, and z to find the resource. In most cases, there would be just one entry in the Iterator anyway. What do you think? I've also attached my first draft at a FAQ.xsltmark. dalibor topic __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
FAQ.xsltmark
Description: FAQ.xsltmark
