[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: performance benefits of XSL3.0

Subject: Re: performance benefits of XSL3.0
From: "Ihe Onwuka ihe.onwuka@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 19 Apr 2016 19:49:59 -0000
Re:  performance benefits of XSL3.0
You should also check what % of time is spent in the chunking phase vs the
transformation phase to see where to focus your efforts.

On Tue, Apr 19, 2016 at 3:37 PM, Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> SAX is a very low-level way of streaming XML; XSLT 3.0 is a very
> high-level way of doing it. The main benefit of using a high-level approach
> to anything is not machine performance, but programmer productivity: you
> get a correct program running with a fraction of the effort. Another factor
> is whether the high-level software is smarter than the programmer writing
> the low-level code. That depends on the skills of the programmer: a few
> programmers will do a brilliant job, but most will probably make a mess of
> it. For example, it's a reasonable to assume that Saxon's multi-threading
> is more likely to bug-free than multi-threading code written by the average
> Java programmer; but I have no idea whether your programmers are below or
> above average.
> With any exercise looking at a possible course of action to improve
> performance, you need to start with measurements and targets. What is your
> current performance, how far does it fall short of requirements? Then you
> need to understand where the current performance is going. You say that
> XSLT is contributing to the large processing times, but do you know why? It
> could be one inefficient XPath expression that could be rewritten to solve
> all your problems. Sometimes all the cost is in stylesheet compilation, and
> there are ways of dealing with that. If you don't know exactly where the
> bottlenecks are currently, then any exercise designed to remove them has a
> good chance of failing. It may be worth exploring alternative approaches
> experimentally just to collect data, but treat it as an experiment: just
> another thing to measure to improve your understanding.
> Michael Kay
> Saxonica
> On 19 Apr 2016, at 19:28, Mailing Lists Mail daktapaal@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> Dear All,
> Need some quick help.
> We are in a business of processing xmls and these come in big loads. some
> of them running real big. We have application that needs to convert these
> incoming XMLS into our internal XMLs and persist the data. We use XSLT as
> our transformation layer. We are totally convinced we need XSLT to carry
> out our job , obviously because of the ease of coding and the powerful
> language constructs of xslt. Off late we have noticed that the XSLT has
> contributed hugely to the large processing times.
> We are using Sax parsers to chop the big XMLs into meaning ful chuncks and
> process each of these chunks in parallel .and we use XSLT2 and saxon to
> process the individual chunks.
> My question here is, if I shift to XSLT3 and do not change my code, will
> it still give me any performance benefits over the XSLT2 . I understand
> that the XSLT3 has a slightly different approach to XSLT programming (
> losing certain axe etc.). Will the xslt3 processor read the input xml in a
> different way?
> I am hoping that my question is clear ..
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://-list/293509> (by email)
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/1005724> (by
> email <>)

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.