[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] performance benefits of XSL3.0

Subject: Re: [xsl] performance benefits of XSL3.0
From: "Ihe Onwuka ihe.onwuka@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 19 Apr 2016 19:49:59 -0000

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