Any java developer who has touched standard java DOM parser, knows that this default XML parser coming with JDK is extreme memory hog. And this boils down into bad overall performance (yes, memory allocation is still not free in java).
On that basis following API sounds interesting: VTD-XML: The Future of XML Processing. Interesting point is how memory efficient API is (1.3x – 1.5x of XML doc size, in default parser that is more like 10x).
Definitely requires some investigation… However, caveat-emptor appears to be that this parser cannot be just dropped in, into old codebase. Of course difficulty depends pretty much from how badly DOM specifics are scattered around in codebase; if application code has any sensibility then such dependencies are encapsulated into one place, and trying different parser should be then reasonably easy.
Why default parser is then so bad? One problem is that it tries to be based into generic API, common across different languages, which causes that API more-or-less forbids efficient implementations.
However, licencing model of VTD-XML can be showstopper for various projects, since it’s either GPL, or commercial license, which is seemingly aimed into ”SOA” customers.
Additional references:
VTD-XML: XML Processing for the Future (Part I)