Support #4821

Suggest performance improvement

Added by Libor Valenta 16 days ago. Updated 1 day ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


We have a transform we need to run on large amount of documents like the one provided in the sample. Author of the XSLT claims, that when he runs transform from his oXygen, it completes consistently faster (cca 2x) than when he runs the same transform on the same document from our Java application. We tried to create smallest approximation of the code in the in the attached benchmark.jar (you can run it with java -jar benchmark.jar)

Is there anything we can do on the Java level to make the transform run faster?

Is there any performance improvement advice I can pass to the XSLT developer?

Anything that would reduce the transform time would be appreciated. Thank you.


#1 Updated by Michael Kay 15 days ago

  • File deleted (benchmark.jar)

#2 Updated by Michael Kay 15 days ago

I have deleted the attachment because it contained a license file. Please take care to keep license files secure.

#3 Updated by Michael Kay 15 days ago

The most obvious thing that comes to mind from a quick look at your code is: don't use a DOMSource. Saxon is about 5-10 times slower processing a DOM tree than using its own internal TinyTree model.

#4 Updated by Michael Kay 7 days ago

  • Status changed from New to AwaitingInfo
  • Assignee set to Michael Kay

Please let us know whether changing from DOMSource to Saxon's native TinyTree accounts for the difference.

If we don't hear further from you we will close this.

#5 Updated by Libor Valenta 1 day ago

Thanks Michael and sorry for the license file, I didn't realize tickets are accessible to broader public. How do we really get the TinyTree? We ended up using SAXSource, and Apache Xerces with cache for DTDs, that helped substantially.

#6 Updated by Michael Kay 1 day ago

If you supply the input as a SAXSource then Saxon will construct a TinyTree by default, so it's doing the right thing here. You can exercise more control for example by using Saxon's DocumentBuilder class to build the tree.

Can we close this now?

#7 Updated by Libor Valenta 1 day ago

Yes, we can close this ticket. Thank you!

#8 Updated by Michael Kay 1 day ago

  • Status changed from AwaitingInfo to Closed

Please register to edit this issue

Also available in: Atom PDF