Project

Profile

Help

Performance drop between v9.0.x and v9.1.x

Added by Anonymous about 15 years ago

Legacy ID: #6423717 Legacy Poster: Alexandre Delarge (adelarge)

Hello Mickael, After I upgraded Saxon from v8.7.3 to v9.1.0.5 in order to solve a problem on the concurrent usage of compiled XQuery objects, I noticed a severe performance degradation. To get a measure of that, I wrote a test class that executes the following set of operations: - Load 2 XML documents into DOM document instances using JDK embedded Xerces version. - Use Saxon to execute an identity transformation from DOM to String onto each DOM. - Use Saxon to apply a different XQuery transformation for each XML file, and output both to String and DOM. The reason why I use 2 XML files and 2 separate XQuery files is because I wanted to determine how big was the degradation on: - a "small job" (i.e. apply simple XQuery on a small XML file). - a "big job" (i.e. complex XQuery over a big XML file). So I measured the performances of Saxon using the following strategy: - 100 iterations of each operation are performed to "warm up" the runtime execution with class loading and HotSpot optimizations. - 1000 iterations of the same exact operation are then executed, and the total execution time is recorded. - The total execution time is the difference between 2 calls to the System.nanotime() method made before and after the 1000 iterations. At first, I executed my tests other 3 versions of Saxon: - v8.7.3 (initial version) - v9.1.0.5 (the one I upgraded to) - v9.0.0.1 (intermediate version taken from Sourceforge) While v9.0.0.1 recorded slightly better performances than v8.7.3, version 9.1.0.5 performed a lot worse... After that I ran my test again over the last v9.0.x I could find, and v9.1.0.5, hoping I could confirm the difference is clearly between the v9.0.x and v9.1.x series. Here are the results of my test, executed using the same test class and these 2 Saxon versions (I used JDK v1.6.0_10 to both compile and execute my tests): ================================================= Testing Saxon version 9.1.0.5 XQuery transformation: warm=100 ; measure=1000 Identity transformation: warm=100 ; measure=1000 XQuery 1 transform: XQuery to string total = 13383238093 XQuery to string averg = 13383238 XQuery to DOM total = 14810014402 XQuery to DOM averg = 14810014 XQuery 2 transform: XQuery to string total = 1232768131 XQuery to string averg = 1232768 XQuery to DOM total = 1228801705 XQuery to DOM averg = 1228801 Identity 1 transform: Total = 9143027675 Averg = 9143027 Identity 2 transform: Total = 461751982 Averg = 461751 ================================================= Testing Saxon version 9.0.0.6 XQuery transformation: warm=100 ; measure=1000 Identity transformation: warm=100 ; measure=1000 XQuery 1 transform: XQuery to string total = 6498402730 XQuery to string averg = 6498402 XQuery to DOM total = 6665119729 XQuery to DOM averg = 6665119 XQuery 2 transform: XQuery to string total = 115673082 XQuery to string averg = 115673 XQuery to DOM total = 95874197 XQuery to DOM averg = 95874 Identity 1 transform: Total = 9155856681 Averg = 9155856 Identity 2 transform: Total = 451998508 Averg = 451998 ================================================= Few notes about this test: - "XQuery 1 transform" and "Identity 1 transform" are performed on the "big" XQuery and XML files. - "XQuery 2 transform" and "Identity 2 transform" are performed on the "small" XQuery and XML files. Then the observation: - Both Saxon versions do produce the same exact output in term of resulting XML. - Identity transformation is slightly faster in v9.0.0.6 than in v9.1.0.5. - "XQuery 1 transform" is roughly 2 times slower on v9.1.0.5. - "XQuery 2 transform" is roughly 12 times (!) slower on v9.1.0.5. So do you have any idea why I observe such degradations between both versions ? I attach the eclipse project with the source code of my test with this post to enable reproduces. The archive also contains a copy of the XML/XQuery files I used. Thank you by advance for any feedback on that issue. Regards, Alex.


Replies (8)

Please register to reply

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6423724 Legacy Poster: Alexandre Delarge (adelarge)

Hmm I can't attach a file to the forum (?), I'll send you my test code by email right away. Regards, Alex.

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6424324 Legacy Poster: Michael Kay (mhkay)

Thanks for the information. I do run performance regression tests at each release but they obviously don't cover all cases (and in fact, they don't cover DOM input or output at all). If you can supply the tests in a form that I can run, I'll be happy to investigate. You can post attachments to the "support requests" tracker, or if they are confidential, you can post them directly.

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6426619 Legacy Poster: Alexandre Delarge (adelarge)

Hello again, Thanks for your reply, did you receive my email with the test code & files ? If not, then I'll try the "support requests" :). Regards, Alex.

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6426716 Legacy Poster: Michael Kay (mhkay)

No, I haven't received the files.

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6427503 Legacy Poster: Alexandre Delarge (adelarge)

I've posted them under support request 2601043 then ! Thanks. Alex.

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6433276 Legacy Poster: Michael Kay (mhkay)

What's happening here is that there's been a change (probably unintentional, but it's a messy area) in XQueryEvaluator.setContextItem(), and indeed in DocumentBuilder.build() and in Configuration.buildDocument(), which it calls. When given a DOMSource, in 9.0.0.x these interfaces copied the DOM tree to create a Saxon TinyTree, whereas in 9.1.0.x they wrap the DOM tree in a Saxon wrapper. The first point to note is that both strategies are very inefficient compared with building a Saxon tree in the first place and using that as the input. Only use DOM trees as Saxon if you really have to, and if you can afford the substantial performance penalty. Secondly, wrapping is more efficient than copying if the document is large and the query is simple; copying is more efficient if the document is small or the query is complex. But there's also a functional difference; if you want the query to select nodes in the input document that are then used for further processing, you want these to be the original DOM nodes, not copies. Also, of course, copying is likely to use more memory. So I think that for XQueryEvaluator.setContextItem(), given a DOMSource as input, wrapping is the right strategy even though it is taking longer in your examples. In your case you are better off (if you really have to start with a DOM) copying it to a TinyTree before doing the query. That raises the question of how best to do the copying.... In the next release, to try to sort this situation out, I am changing the code so that DocumentBuilder.build() always copies the tree, regardless of the kind of source, and DocumentBuilder.wrap() is called if you want to wrap it. For the moment, the best way is probably to wrap your DOMSource in an AugmentedSource with setWrapDocument(false): AugmentedSource as = AugmentedSource.makeAugmentedSource(domSource); as.setWrapDocument(false); xqueryEvaluator.setContextItem(as); (not tested)

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6433393 Legacy Poster: Michael Kay (mhkay)

Sorry, my references to setContextItem() should have been to setSource().

RE: Performance drop between v9.0.x and v9.1.x - Added by Anonymous about 15 years ago

Legacy ID: #6438669 Legacy Poster: Alexandre Delarge (adelarge)

Thank you Michael, using a XdmNode copy of the document I can observe similar performances between v9.1.0.5 and v9.0.0.8 / v9.0.0.6. For information to other potential readers, here is the additional code: [...] // Prepare base objects Source srcDOM = new DOMSource(dom); XQueryEvaluator evaluator = xQuery.load(); /* * Use Saxon DocumentBuilder to copy the DOM to Saxon model. * We use a class of ours to augment visibility of constructor: * net.sf.saxon.s9api.DocumentBuilder(Configuration) */ XdmNode source = new MyDocumentBuilder( evaluator.getUnderlyingQueryContext().getConfiguration() ).build(srcDOM); [...] // Use the XdmNode instead of the DOMSource evaluator.setSource(source.asSource());

    (1-8/8)

    Please register to reply