If you use the Xalan API directly, you can use impelementation specific optimizations that can’t be expose via the JAXP API layer. Or tell the jvm to use a different JAXP impl. Eg Saxon, which might implement Xpath eval differently.

Sorry, it’s been 4 years since I looked into this, I’m going on memory. The best solution I could come up with given my constraints at the time was the one that outlined.

If you discover a better solution, please let me know, I’d be very interested!

Isn’t there any other implementation out there? Cause this small document cannot be so hard to process… I see it’s a big problem for the library as a whole…

You say that I should try to use xerces library directly. But as far as I know, xerces is not an xpath evaluator, that implementation resides on xalan. Did you mean I should try using XalanApi class directly? what would be the advantage?

The strange thing is that I’ve tried to use the same expression (let’s say /Data/Record[x]/Field[@name='Y']/@value ) but not on different nodes variables. Instead, I give up using relative expressions and use always absolute expression (from the root node I mean). The performacen decreases dramatically with a 504kb file, for instance…