Saxon

Taking another look at this, I see that we're talking here about an "identity transformation" (@TransformerFactory.newTransformer()@) rather than a true XSLT transformation. It's not clear at first sight why this should use any significant amount of memory.

It could be that the memory is caused by Saxon's DOM walk using node.getChildNodes()@, and that @getFirstChild()/getNextSibling() would perform better. It's also possible that finding all the namespaces could be more efficient.

I believe Xalan has private knowledge of the internals of the Xerces DOM, and it's possible it may make use of this to achieve things that Saxon can never achieve using public (and portable) DOM APIs. For example, discovering all the in-scope namespaces on an Element node is fairly horrendous using only public APIs. But I'll take a look at it.

I'm seeing consistent figures: for an identity transformation of a 1Mb document

Saxon: 22ms in 22Mbytes

Xalan: 13ms in 14Mbytes

Note we're measuring allocated memory, not used memory: I think a lot of the memory is used very transiently.

Java profiling suggests that a lot of the time is going in String.intern(), which is invoked from org.xml.sax.helpers.NamespaceSupport - I'm a little surprised to find we are using this. The interning of strings could also be accounting for memory usage.

I've changed the way namespaces are managed by the DOM walker and the results are looking promising:

Saxon: 25ms in 8037184bytes

       Xalan: 13ms in 14599008bytes

Saxon: 15ms in 8844032bytes

       Xalan: 19ms in 14599008bytes

Saxon: 16ms in 7533856bytes

       Xalan: 13ms in 14599256bytes

Saxon: 10ms in 7533856bytes

       Xalan: 13ms in 14599008bytes

Saxon: 12ms in 7533856bytes

       Xalan: 14ms in 14599008bytes

Saxon: 11ms in 7533856bytes

       Xalan: 17ms in 14599008bytes

That is to say, the memory is now significantly better than Xalan, and the execution time is broadly comparable.

The test case I was using didn't actually have any namespaces.

I now need to do a lot of functional testing - ideally including programmatically built DOM trees which can display all sorts of oddities. Unfortunately there aren't as many unit tests of this area as I would like.

At present I'm having some difficulty reproducing the previous results for a non-namespace-aware DOM. It's not helped by the fact that (a) I have hardly any tests for that case, and (b) the spec is totally unclear on what should happen. The spec for DOMSource says that XSLT requires the DOM to be namespace-aware, but it doesn't say that for the identity transform. It's also not helped by the fact that the DOM provides no interrogatives, so you can't actually ask whether it's namespace-aware or not. Everything to do with DOM is so frustrating!