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(_at_)saxonica(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)gmail(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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 <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--