Subject: Re: [xsl] Saxon performance difference in eClipse and App Server From: Michael Kay <mike@xxxxxxxxxxxx> Date: Wed, 15 Dec 2010 17:19:59 +0000 |
Michael/Andrew,Yes, that's progress. I'm afraid I don't know why you're still seeing a difference. Other than perhaps that Eclipse is running without other concurrent processes sharing the resources?
thanks for the advice. Moving away from using a DOMSource to a StreamSource has cut the App Server times from 700-800ms to 150-180ms, so that was really worthwhile.
It also has a similar effect to the [same] code when I run it in eClipse, which now shows an average time of around 50ms.
I'm still not sure why there remains a 3 to 4 times overhead for running the same code but at least in actual terms things are much better.
With a StreamSource, that's what you're using.I would now like to see if there is any further improvement possible by using Saxon's native tree
I don't understand the difference - the Templates object is a "compiled" stylesheet.As you can see I use Templates since the XSLT is relatively stable and is executed 000's of times with different source XML (its always XML to XML transformation in this case).
I wondered about pre-compiling the stylesheets and caching them instead,
I suspect that's discussing use of XSLTC which compiles down to bytecode?but I am slightly wary because of comments I have seen in other threads about how these might be specific to the version of the processor (ie. not guaranteed to be backwards compatible)
It's always hard to do performance engineering properly via Q&A on a forum like this. Answering your question professionally needs a deep understanding of the systems architecture and the workload requirements. Having said that, performance is full of contradictions - good performance depends on good top-down system design, but bad performance is often caused by a simple avoidable mistake somewhere in the system where someone didn't understand enough about the technology they were using - e.g. your use of DOMSource.What I am really trying to get to the bottom of here is whether the native language perfromance advantage of the integration platform that we are using is significant enough to suffer the need to recompile and redeploy larger parts of the application when changes are needed, or whether we can get adequate enough perfromance out of using XSLT and benefit from a less disruptive and potentially more flexible change capability.
Michael Kay Saxonica
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Saxon performance differe, Fraser Goffin | Thread | Re: [xsl] Saxon performance differe, Martin Honnen |
Re: [xsl] Saxon performance differe, Fraser Goffin | Date | Re: [xsl] Saxon performance differe, Martin Honnen |
Month |