Saxon diaries

XQuery Update and Node Identity

Michael Kay — Thu, 14 Feb 2008 10:36:45 +0000

An interesting little spat on the XQuery internal mailing list over the last couple of days on the question of whether or not XQuery Update guarantees to preserve node identity. The spec says that it does. Someone remarked during a telcon that there were difficulties meeting this requirement in a SQL/XML environment. After the meeting I sent an email claiming that the assertion in the spec that updates preserve node identity is untestable and therefore ought to be removed.

Further progress on XQuery Update

Michael Kay — Wed, 02 Jan 2008 14:15:13 +0000

I've no got to the point where my XQuery Update implementation is passing almost all the published tests. That doesn't mean its complete, because the test suite doesn't cover certain areas, such as revalidation of updated documents. But it's looking good.

Progress on XQuery Update

Michael Kay — Wed, 19 Dec 2007 19:03:48 +0000

A progress report on the state of the XQuery Update implementation in Saxon, in particular, a list of things still to be done and some thoughts on how they might be tackled.

Implementing XQuery Update

Michael Kay — Tue, 11 Dec 2007 18:00:30 +0000

I've been asked a number of times whether I planned to implement XQuery Updates, and my answer has always been that I would do it when the time was right (i.e. when the spec seemed to be stable enough and when I had a suitable gap in my hectic schedule)...

Final Draft of XQJ

Michael Kay — Wed, 21 Nov 2007 16:29:45 +0000

A "Final Draft" of XQJ has been published (http://jcp.org/en/jsr/detail?id=225). There aren't many changes, but this time the specification is accompanied by actual interface definitions, and by a test suite. Swapping in the published interface definitions for my previous handmade versions proved no trouble - one or two discrepancies as regards which methods throw exceptions, and one or two methods that have had an extra argument added. Running the test suite is likely to be a bit more effort....

Transforming 20 Gigabytes

Michael Kay — Tue, 25 Sep 2007 13:20:28 +0100

My heart sank when I received an email yesterday from a Saxonica customer reporting a failure when running a transformation on a 20Gb source file (using the "streaming" capabilities described at http://www.saxonica.com/documentation/sourcedocs/serial.html.) It was apparently failing half way through with no error message of any kind. How do you go about debugging such a problem, especially when you're in a different continent from the client?

Document Projection

Michael Kay — Sat, 25 Aug 2007 10:34:13 +0100

Document Projection [1] is a technique invented by Amélie Marian and Jérôme Siméon designed to reduce the amount of memory occupied by a source document used by a query or transformation. The idea is to analyze the query and determine what nodes it is capable of accessing, and then while parsing and building the document, to filter out all those nodes that the query can never access. I decided to have a go at implementing this in Saxon...

A new XQJ draft

Michael Kay — Wed, 13 Jun 2007 22:54:32 +0100

XQJ is the proposed XQuery API for Java. A new draft of the XQJ specifications came out yesterday, with the psychologically significant version number of 0.9, and I spent today updating Saxon's implementation to conform. The spec can be downloaded from http://jcp.org/en/jsr/detail?id=225 ....

Path Expressions Revisited

Michael Kay — Fri, 27 Apr 2007 15:01:39 +0100

The core of XSLT and XQuery performance is the ability to evaluate simple path expressions efficiently. This area of Saxon has been untouched for some time, and I tend to assume it has been tuned to death. But I've always had a nagging feeling that the machinery created for evaluating a multi-step path expression might have room for improvement....

Saxon vs Xalan Performance; and DOM

Michael Kay — Sat, 31 Mar 2007 17:15:42 +0100

I had an email from a customer the other day that started "It is quite unusual for Saxon's performance to be worse than Xalan's". It turned out to be an XSLT stylesheet that was taking around 3950ms under Saxon, and just 1370ms under Xalan. A quick look at the application showed that it was using a DOMSource and a DOMResult. I changed that to use a Saxon TinyTree for both the source and result (which only involved changing a couple of lines of code) and the Saxon timings came down to about 400ms. Pride restored...

Assertions in XML Schema

Michael Kay — Tue, 06 Mar 2007 13:09:13 +0000

I've been implementing the new facility in XML Schema 1.1 for defining assertions, in terms of XPath expressions. It's a great feature. You could do something similar before, of course, using Schematron - but no-one really wants to do to separate validations using very different technologies. The new xs:assert clause makes it all much more seamless. As one might expect in a first draft though, there are glitches in the spec.

Unexpected flattery

Michael Kay — Sat, 03 Feb 2007 17:46:26 +0000

There was an unexpected compliment for Saxon on Thursday in an announcement of a new release of Per Bothner's Qexo implementation of XQuery. He slipped in the remark: "some tests are significantly faster than Saxon". More evidence that our competitors regard Saxon as the product they need to beat, and at the same time an admission that for most tests, Saxon runs faster than this particular engine...

How not to fold constants

Michael Kay — Sat, 20 Jan 2007 00:04:03 +0000

I'm back to work on the Java code-generation for XQuery. The challenge is to improve the test coverage. With 14000 tests in the W3C test suite, one would think the coverage would be pretty good; but the problem is that many of the tests use literal constants, which means the whole query can be evaluated statically by the XQuery analyzer, before the code generator gets a look in. Early evaluation of expressions at compile time is known rather quaintly in the compiler literature as "constant folding". We should be able to improve the coverage of the code generator testing simply by not doing constant folding....

XML Schema Tests: progress report

Michael Kay — Wed, 03 Jan 2007 18:19:51 +0000

As reported in my previous posting, I've been working on the new XML Schema Test suite. Achieved a significant milestone today: all the tests in the Microsoft part of the test suite are now "done". That's around 14600 tests. Of these I have queried the results of 858 tests (you can find the bug reports in the W3C public bugzilla). Most of these are illegal regular expressions in supposedly valid schemas. Of the remainder, Saxon fails on 22 tests for known reasons, and passes on the remainder.

The failures are essentially for three reasons: (a) hitting resource limits on large minOccurs/maxOccurs values; (b) Saxon has a better algorithm for testing type subsumption than the one in the spec (it's essentially anticipating the XML Schema 1.1 spec here), and (c) there are three tests in which a user-defined type is derived directly from xs:anySimpleType, and although the spec appears to allow this, it's not at all clear what it's supposed to mean, so Saxon disallows it.

I had to fix quite a large number of Saxon bugs to get to this point, but they were almost all very obscure corner cases.

Next step is to tackle the Sun and NIST tests. On past experience these will be easier.

New W3C XML Schema Test Suite

Michael Kay — Thu, 14 Dec 2006 16:02:34 +0000

A few weeks ago the W3C Schema working group published a new test suite, containing nearly 40,000 tests. Since then, I've been putting a fair amount of effort into reconciling Saxon's results on these tests with the published results.

Compiling Q10

Michael Kay — Wed, 08 Nov 2006 11:05:24 +0000

The last remaining query in the XMark benchmark where the compiled code was running significantly slower than the interpreted code was Q10.... Inlining of variables eliminates the tree copy operation, which improves the performance from 301ms to 104ms.

First compiled XMark results

Michael Kay — Mon, 06 Nov 2006 18:34:09 +0000

The code to compile XQuery into Java has now advanced sufficiently that I can run all the XMark benchmark queries, producing correct results, and reproducing the Saxon-SA join optimizations. First results are shown below: there's clearly room for further work in some areas, but overall it's an encouraging milestone. All timings in milliseconds...

Altova Mudslinging

Michael Kay — Sat, 28 Oct 2006 18:32:57 +0100

A number of users have written to me suggesting that I respond to Altova's latest customer newsletter in which they make the rather suprising claim that their XSLT processor is three times faster than Saxon. At least they had the decency to describe how they measured it - by running a thousand or so conformance tests from the W3C test suite using a batch script in which each transformation was run individually from the command line. Any reasonably competent user knows that that's a hopelessly inefficient way of running Java programs...

Progress on XQuery compilation

Michael Kay — Tue, 24 Oct 2006 08:26:52 +0100

A progress report: I'm now within a whisker of being able to compile the whole of the XQuery Test Suite into Java code. One or two negative tests generate code that won't compile, but the problems are minor. So far, however, I've only actually executed a very small sample of the tests. The next stages, which will overlap to some extent, are (a) to get the generated code working correctly, (b) to make sure it performs (which includes generating code for some of the optimizations currently done dynamically by the interpreter), (c) general clean-up: there's a lot of repetitive code that was generated by cut-and-paste, and therefore many opportunities for refactoring, and I don't want to be fixing the same bug in a dozen places, (d) removing restrictions in the current implementation, for example there's no support currently for extension functions, (e) diagnostics, especially the quality of run-time error reporting and tracing, and (f) packaging, for example defining the interfaces to control the compilation process. That's a fair bit of work still to do, even though the bulk of the code may now have been written.

An interesting problem emerged in using the XQTS tests: a very large number of them contain expressions that are actually evaluated at compile time during the constant-folding process. To get reasonable coverage for the Java code geenrator I therefore had to suppress such constant-folding operations, which I basically achieved by wrapping string and numeric literals in an artificial function call. This in turn generated some very obscure expressions which in one or two cases broke the existing interpreter! It also turns out there are a few features missing from the test suite, some of which are quite tricky: not only things that are intrinsically non-portable like extension functions and dynamically-selected collation URIs, but also rarely-used but well-defined constructs like X/position() and X/last().

Choosing Java class names

Michael Kay — Fri, 06 Oct 2006 12:05:32 +0100

Years ago, I took some childish pleasure in naming the class that does whitespace-stripping in Saxon "Stripper.java".

Guess what? The second-most popular entry point to the Saxonica web site from Google is .../javadoc/net/sf/saxon/event/stripper.html

The punters must be very disappointed. I wonder how much I'm paying for the wasted bandwidth?

It's one way to boost my google rankings, I suppose.

Still Compiling the Knight's Tour

Michael Kay — Tue, 03 Oct 2006 19:30:53 +0100

I wrote on 20 September that I was getting the compiled Knight's Tour stylesheet to run in 39.3 ms, compared with 45.9 ms for the interpreted code, and that I didn't think it would be hard to improve on this. Well, it's now down to 9.41 ms. (Thie compares with the figure of 900 ms given in my book, for an earlier version of Saxon and a previous laptop.) But a lot depends on what you mean by "hard"...

Compiling the Knight's Tour

Michael Kay — Wed, 20 Sep 2006 22:15:46 +0100

A progress report on query compilation: I've now got to the point where I can compile the knight's tour query (tour.xq in the Saxon samples distribution) into Java code, and execute it with correct results. It's running in 39.3ms, compared with 45.9ms for the interpreted code, which isn't wildly exciting, but there's enormous scope for tuning the generated code and it shouldn't be hard to improve on this figure very significantly.

More experiments with compilation

Michael Kay — Fri, 15 Sep 2006 16:25:34 +0100

A couple of months ago (see http://saxonica.blogharbor.com/blog/_archives/2006/7/24/2157486.html), I reported on some experiments with compiling path expressions into Java code. The results were not enormously encouraging, but I've been taking the idea forward, on a slighly different front.

This time round, rather than compiling the low-level code for navigating a TinyTree, I'm compiling the higher level logic for evaluating path expressions, FLOWR expressions, and the like. I've done enough work to compile the whole of the XMark XQuery benchmark into Java code, with the exception of one query (Q18) that uses a user-defined function. The code generation is not particularly smart at the moment - in particular, it's always doing eager evaluation of expressions - but nevertheless, the speed of some of the queries has doubled. The bad news is that others are slower; but this is early days.

This is a bigger pilot than the previous experiment I reported, in that I've written code to compile about 50 of the expression classes generated by the Saxon parser and optimizer. That's about a fifth of the total, so there's a long way to go. The next stage is to put in some of the fundamentals like function calling and lazy evaluation, and convince myself that the performance gains make it worth doing. After that there's a long slog to get full coverage of the XSLT and XQuery languages, and to test everything. The testing won't be easy, because although there are now large XQuery and XSLT test suites around, many of the expressions they contain are compile-time constants.

Compiling to Java seems a sensible choice at the moment. Going straight to bytecode would be a lot more effort, and would introduce a high risk of bugs; and the extra benefit seems marginal. One unexpected benefit is that the generated Java gives a very clear view of the execution strategy for the query, which makes it much easier to spot opportunities for improving the optimizer.

There are some basic limitations in the approach. There's no saving in the time or memory used to build the source document. The generated Java code still calls the same iterators to navigate the axes over the source document, and the same serialization methods to produce the output. Together, those run-time routines account for a large part of the query cost, which isn't going to come down. But there's always scope for moving more code into the compiled part as opportunities show themselves. I'll set the target as a 50% improvement in execution time, but I think that's probably a stretch.

Zounds! I was never so bethump'd with words

Michael Kay — Sun, 13 Aug 2006 16:41:36 +0100

Saxon is implementing Unicode codepoint collation simply by doing a Java string compare, and this is incorrect in the case of strings containing characters whose Unicode codepoint value is greater than 65535. This kind of bug is irritating, because hardly anyone is going to be affected by it, yet fixing it will impose a cost on everyone because string comparison will be slower.

Tail recursive functions

Michael Kay — Tue, 01 Aug 2006 22:55:25 +0100

I made some minor changes to the details of expression evaluation a few days ago, and found that this broke the code for optimizing tail calls in recursive functions. Since that code has a nasty habit of breaking when I make small changes in this area, I decided that it was time for an overhaul...

Tuning the Chess-FO stylesheet

Michael Kay — Thu, 27 Jul 2006 13:22:48 +0100

In an interesting post (at least partly influenced by my compilation experiments) Anton Lapounov has published some Saxon performance measurements for a number of 1.0 stylesheets. I'm intrigued that I get faster performance for Saxon 8.7.3 than for 6.5.5, whereas he gets the opposite. I decided to look into the performance of one of these stylesheets a bit more closely and see how it can be improved. The one I chose is the Chess-FO stylesheet which takes as input the record of moves in a chess game and produces as output an XSL-FO document showing the successive positions.

Firstly, it's clear just from looking at the source code that evaluating path expressions doesn't play much of a role in this code. It's spending most of its time constructing output. There are a fair number of template calls, some of them tail-recursive. The ratio of output size to input size (377Kb from 3Kb) is unusually large, so we should expect that the cost of creating elements and serializing them will dominate.

I started by seeing how far I could improve the performance simply by tuning the XSLT code as written. The baseline execution time was 301ms (in this, and all subsequent figures, I'm reporting the second-best out of nine runs, running from the command line with the -9 option to run the transformation nine times, and the -t option to output the results.

First I modified the stylesheet to say version="2.0", and put in a couple of explicit type conversions in places where the code had been implicitly converting between strings and numbers. Time now 280ms.

My next move was to profile the stylesheet execution using the -TP option on the command line. This generates a trace file with timing information, which can be analyzed using the timing-profile.xsl stylesheet (in the samples/analysis directory of the Saxon distribution). This showed one template dominating the execution time: template render-chessboard-cell. So I focused my efforts on this template, which reads:

  <xsl:template name="render-chessboard-cell">

    <xsl:param name="col-number" select="1"/>

    <xsl:param name="row-number"/>

    <xsl:param name="row-content"/>

    <xsl:variable name="cell-background">

      <xsl:choose>

        <xsl:when test="($col-number mod 2 = 0 and $row-number mod 2 = 0) or

                        ($col-number mod 2 != 0 and $row-number mod 2 != 0)">

          <xsl:value-of select="'b'"/>

        </xsl:when>

        <xsl:otherwise>

          <xsl:value-of select="'w'"/>

        </xsl:otherwise>

      </xsl:choose>

    </xsl:variable>

    <xsl:variable name="cell-content" select="substring($row-content, $col-number, 1)"/>

    <fo:table-cell>

      <xsl:if test="$cell-background = 'b'">

        <xsl:attribute name="background-color">#C0C0C0</xsl:attribute>

      </xsl:if>

      <fo:block>

        <xsl:if test="$cell-content != 'x'">

          <xsl:call-template name="piece-image">

            <xsl:with-param name="piece-name" select="$cell-content"/>

            <xsl:with-param name="cell-background" select="$cell-background"/>

          </xsl:call-template>

        </xsl:if>

      </fo:block>

    </fo:table-cell>

    <xsl:if test="$col-number &lt; 8">

      <!-- recurse to the next cell -->

      <xsl:call-template name="render-chessboard-cell">

        <xsl:with-param name="row-number"  select="$row-number"/>

        <xsl:with-param name="col-number"  select="$col-number + 1"/>

        <xsl:with-param name="row-content" select="$row-content"/>

      </xsl:call-template>

    </xsl:if>

  </xsl:template>

I started by declaring types on the parameters and variables, and changing xsl:value-of to xsl:sequence (no need to create a text node when you only want a string). Time now down to 210ms.

Then I dealt with the recursion in this template, replacing it by an iteration. The call on this template, as written, was:

    <fo:table-row height="24pt">

      <xsl:call-template name="render-chessboard-cell">

        <xsl:with-param name="row-number" select="$row-number"/>

        <xsl:with-param name="count" select="1"/>

        <xsl:with-param name="row-content">

          <xsl:value-of select="substring($chessboard, $row-number * 8 - 7, 8)"/>

        </xsl:with-param>

      </xsl:call-template>

    </fo:table-row>

The count parameter is noise (it isn't even declared as a parameter: XSLT 2.0 spots this error). The row-content parameter uses the horribly unnecessary RTF construction: it should simply be written as

<xsl:with-param name="row-content" 
     select="substring($chessboard, $row-number * 8 - 7, 8)"/>

And then we can change it to call the template 8 times using <xsl:for-each select="1 to 8">, passing the column number as a parameter. This gave no further time savings, however. Using recursion to do simple iteration is a pain from the usability point of view, but it's not actually inefficient. But to tidy things up further, I removed the recursion to scan over the rows as well. This time the timing came down a little to 191ms.

Then I collapsed the three templates into one, so that the board is printed using two nested for-each loops. Time now down to 130ms!

The body of the template is still inefficient: the calculation of the colour of a cell can be simplified, and we don't need the variable $row-content. It's also passing a parameter cell-background to the template piece-image, which the called template doesn't actually use. So the template now looks like this:

      <fo:table-body>

        <xsl:for-each select="1 to 8">

          <xsl:variable name="row-number" as="xs:integer" select="."/>

          <xsl:variable name="row-content" select="substring($chessboard, $row-number * 8 - 7, 8)"/>

                <fo:table-row height="24pt">

                  <xsl:for-each select="1 to 8">

                    <xsl:variable name="col-number" as="xs:integer" select="."/>

                    <xsl:variable name="cell-number" as="xs:integer" 
                                  select="($row-number - 1) * 8 + $col-number"/>

                        <xsl:variable name="cell-content"  as="xs:string" 
                                      select="substring($chessboard, $cell-number, 1)"/>

                        <fo:table-cell>

                          <xsl:if test="$cell-number mod 2 = 0">

                            <xsl:attribute name="background-color">#C0C0C0</xsl:attribute>

                          </xsl:if>

                          <fo:block>

                            <xsl:if test="$cell-content != 'x'">

                              <xsl:call-template name="piece-image">

                                <xsl:with-param name="piece-name" select="$cell-content"/>

                              </xsl:call-template>

                            </xsl:if>

                          </fo:block>

                        </fo:table-cell>

                  </xsl:for-each>

                </fo:table-row>

        </xsl:for-each>

      </fo:table-body>

No further improvement in performance, though (in fact, this time the second-best time is 140ms, but I'll put that down to random fluctuation).

The next obvious target is the piece-image template, which is using a 16-way xsl:choose statement to replace characters such as P, B, or K with a single Unicode character representing the chess piece. This can clearly be done in a single translate() call.

I thought this would make a significant difference, but the time is stubbornly sticking at 130ms. Still, that's down below 40% of the starting figure.

Rerunning the profiling, the render-chessboard template is still accounting for 80% of the execution time, so there's not much point looking anywhere else. There are still a couple of small tweaks we can make: removing variables that are only used once, and expanding them inline, for example. The best time is now down to 110ms: but I said I would use the second-best, and that's still 130ms. This is probably as good as we are going to get by tuning the stylesheet. The relevant template now looks like this:

  <xsl:template name="render-chessboard">

    <xsl:param name="chessboard"/>

    <fo:table width="192pt"

              height="192pt"

              border="thin solid black"

              start-indent="0.26in"

              end-indent="0.26in"

              font="20pt/0pt Chess">

      <fo:table-column column-width="24pt" number-columns-repeated="8"/>

      <fo:table-body>

        <xsl:for-each select="0 to 7">

          <xsl:variable name="row-offset" as="xs:integer" select=". * 8"/>

                <fo:table-row height="24pt">

                  <xsl:for-each select="1 to 8">

                    <xsl:variable name="cell-number" as="xs:integer" select="$row-offset + ."/>

                        <fo:table-cell>

                          <xsl:if test="$cell-number mod 2 = 0">

                            <xsl:attribute name="background-color">#C0C0C0</xsl:attribute>

                          </xsl:if>

                          <fo:block>

                            <xsl:value-of select="translate(substring($chessboard, $cell-number, 1),

                              'KQRBNPkqrbnpx',

       '&#x2654;&#x2655;&#x2656;&#x2657;&#x2658;&#x2659;&#x265A;&#x265B;&#x265C;&#x265D;&#x265E;&#x265F;')"/>

                          </fo:block>

                        </fo:table-cell>

                  </xsl:for-each>

                </fo:table-row>

        </xsl:for-each>

      </fo:table-body>

    </fo:table>

  </xsl:template>

I expect that the costs are now dominated by constructing and serializing the various FO elements and attributes, which we can't reduce any further. Let's run some profiling at the Java level, by adding -Xrunhprof:cpu=samples to the command line. The only sample points which occur more than once are these:

CPU SAMPLES BEGIN (total = 185) Thu Jul 27 11:58:26 2006

rank   self  accum   count trace method

   1  8.11%  8.11%      15 300106 java.lang.ClassLoader.defineClass1

   2  4.86% 12.97%       9 300316 java.io.FileOutputStream.close0

   3  3.24% 16.22%       6 300001 java.lang.ClassLoader.findBootstrapClass

   4  2.16% 18.38%       4 300311 java.lang.Runtime.gc

   5  1.62% 20.00%       3 300306 net.sf.saxon.functions.Substring.substring

   6  1.62% 21.62%       3 300011 java.util.jar.JarFile.getManifest

   7  1.08% 22.70%       2 300214 com.sun.org.apache.xerces.internal.util.XMLChar.<clinit>

   8  1.08% 23.78%       2 300112 java.lang.Class.forName0

   9  1.08% 24.86%       2 300052 sun.misc.FloatingDecimal.<clinit>

  10  1.08% 25.95%       2 300227 net.sf.saxon.style.StyleElement.processVersionAttribute

  11  1.08% 27.03%       2 300257 java.util.AbstractList.iterator

  12  1.08% 28.11%       2 300256 net.sf.saxon.pattern.Pattern.make

  13  1.08% 29.19%       2 300041 sun.security.provider.Sun$1.run

  14  1.08% 30.27%       2 300207 com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity

  15  1.08% 31.35%       2 300332 java.io.FileOutputStream.open

This doesn't give us much to go on, unfortunately. There's a fair bit of system overhead loading classes, opening files, and running the garbage collector. The most-sampled bit of Saxon code is the substring function, and that's followed by the code for parsing XSLT patterns at compile time. With only a couple of hits on each sample point, this data is pretty random: we need a much longer run for the samples to be meaningful.

So I changed the command-line code in my IDE to run the transformation 1000 times, with these results:

   1 49.97% 49.97%    7979 300137 java.net.PlainSocketImpl.socketAccept
   2 2.12% 52.09%     339 300289 sun.nio.cs.UTF_8$Encoder.encodeArrayLoop
   3 1.79% 53.89%     286 300293 net.sf.saxon.event.XMLEmitter.testCharacters
   4 1.70% 55.58%     271 300312 net.sf.saxon.functions.Substring.substring
   5 1.61% 57.19%     257 300314 java.io.FileOutputStream.writeBytes
   6 1.57% 58.76%     250 300296 net.sf.saxon.value.StringValue.getStringLength
   7 1.42% 60.18%     227 300297 net.sf.saxon.value.StringValue.getStringLength
   8 1.23% 61.41%     196 300305 java.io.FileOutputStream.open
   9 0.97% 62.38%     155 300333 java.io.FileOutputStream.close0
10 0.96% 63.34%     154 300304 java.lang.AbstractStringBuilder.append
11 0.86% 64.20%     137 300345 net.sf.saxon.instruct.LocalParam.evaluateVariable
12 0.85% 65.05%     136 300327 net.sf.saxon.om.NamePool.getCodeForPrefix
13 0.83% 65.89%     133 300307 java.lang.StringBuffer.toString
14 0.80% 66.68%     127 300379 net.sf.saxon.expr.Assignation.evaluateVariable
15 0.79% 67.47%     126 300318 java.lang.AbstractStringBuilder.<init>
16 0.75% 68.22%     120 300366 java.io.FileInputStream.open
17 0.75% 68.97%     120 300468 java.lang.String.<init>

I don't actually know what that dominant call on socketAccept is doing, but I'll assume it's an artefact of the CPU sampling and ignore it. Next to that in importance, we have a number of routines concerned with outputting of characters: UTF-8 encoding (I should have mentioned that I changed the output to UTF-8 to see what the effect would be, and there was none noticeable), Saxon's testCharacters which tests that characters are encodable, and various methods in FileOutputStream. Apart from that there are various methods for string manipulation, and routines for evaluating local variables and parameters.

I see now why changing to UTF-8 encoding made no difference. The routine testCharacters is still called to test whether every character appearing in an element name is present in the chosen encoding. If the encoding is UTF-8, that's clearly unnecessary, so there's something I can fix.

The call on Substring is evaluating the first argument of translate() in the expression

translate(substring($chessboard, $cell-number, 1),

This is a more expensive call than you might imagine, because Saxon has to scan the string looking for Unicode surrogate pairs, which occupy four bytes rather than the usual two: it's not possible to simply index into the string. Similarly, translate() itself has to step through the various strings supplied as arguments, rather than indexing into them directly. This suggests an opportunity to mark strings as "safe" once they have been examined and found to contain no characters outside the 2-byte range. However, there's another clue here: another trace shows that Substring() is calling ItemChecker and CardinalityChecker to perform type checking on one of the arguments. That reminds me that I didn't declare the type of $chessboard (because I wasn't sure what type it actually was). Back to the stylesheet, declare the type as xs:string. Second-best time is now 120ms.

There are quite a few calls on getDisplayName() in the NamePool, which does string concatenation to construct (prefix + ':' + localname). This is happening in the serializer when writing start tags. There's scope here to reduce the cost by caching, or by getting the components of the name separately, or perhaps even by storing the display name explicitly in the NamePool rather than reconstructing it on demand. But at user level, perhaps I could reduce the cost by making the FO namespace be the default namespace? Wow: second-best time is now 100ms.

I'll leave it there for now: I've cut the execution time to a third, by some pretty simple source-level changes to the stylesheet. It's encouraging to know that this can be achieved with a stylesheet even when there are no obvious gross inefficiencies in the coding. It does require some exploitation of XSLT 2.0 features, of course. I've also identified one or two places where I think Saxon could be tweaked internally. And I hope I've given you, dear reader, a demonstration of the methodology I use when tackling performance problems.

Saxonica, of course, is always pleased to tackle performance-related consultancy work.

Experiments with Compilation

Michael Kay — Mon, 24 Jul 2006 18:28:39 +0100

Some XSLT processors (XSLTC for example) compile stylesheets into Java bytecode (or equivalently, other intermediate codes such as CIL on .NET). I believe the technique is also used by some XQuery processors. Some users assume that a product that compiles to bytecode will be necessarily faster than an interpreter. I've tended to argue that high-level optimizations are more important, and that compiling expressions to bytecode might reduce the scope for high-level optimizations, if only by making them more complex to implement and debug. I set out today to do some experiments....

Streaming Mode on large documents

Michael Kay — Tue, 04 Jul 2006 18:42:41 +0100

Coincidentally, the day after my successful efforts to get the XStream benchmark running using the Saxon-SA streaming mode for large documents, (see previous post) a Saxon-SA customer sent me a problem: they needed to transform a 450 Mb file and wanted to know whether this facility would crack the problem. The answer, sadly, was no...

Push and Pull

Michael Kay — Mon, 03 Jul 2006 15:40:04 +0100

Alain Frisch of INRIA has been doing some work on streaming transformations, including the development of a language called XStream...

XIME-P in Chicago

Michael Kay — Sat, 01 Jul 2006 06:23:01 +0100

It's been a heavy month for travelling: Grenoble, Dusseldorf, Prague, Paris, Edinburgh, and now Chicago for the one-day XIME-P XQuery workshop.

I presented a paper describing a proposal for an XQuery extension to tackle positional grouping problems. You can download both the paper (PDF) and the Powerpoint slides. This is essentially a conference of XQuery researchers and implementors, co-located with the SIGMOD database conference. The main reason I put this paper forward was that I was irritated at last year's workshop by the "data" orientation of most of the speakers, and felt there was a need to stress that XML, unlike relational data, is intrinsically ordered and that there are many practical tasks that need to take the ordering into account. As it happens, there was much more emphasis on narrative ("document-oriented") XML at this year's event, including a couple of papers on parallel markup - one of the speakers informing the audience, as if it was a new discovery, that XML was invented by markup people and not by database people.

My paper on positional grouping got a reasonably good reception. Some people seemed to think that extensions to FLWOR expressions would be a better approach than a free-standing new construct. I'm not convinced - I haven't seen the use cases that require it, and in any cases FLWOR expressions are already quite complicated enough. I think it was a bad mistake adding the "O" for "order by" rather than having a free-standing "sort X by Y" construct. Apart from anything else, it bends the data model by requiring the concept of tuples, which makes it hard to implement, hard to explain, and apparently has made it impossible to define the formal semantics.

The XQuery people, by and large, still try to pretend that XSLT doesn't exist. Don Chamberlin proudly announced that the word "XQuery" gets 11,900,000 hits on Google, without mentioning that "XSLT" gets 90,200,000. He also mentioned evidence of lively traffic on internet XQuery forums, whereas my perception is that xsl-list still has ten times the traffic of all the XQuery sites put together (and it was much higher in the early days). Perhaps he didn't even think to look, I don't know. All the debate in the corridors and in the panel session seemed to make the assumption that the biggest competitor to XQuery was not XSLT but LinQ. For academics, this blind spot is understandable - they only think things are important if lots of academic papers are being written on the subject. It's harder to understand in the case of people working in the industry.

Dana Florescu presented an important paper on XQueryP, a proposal for adding procedural extensions to XQuery - statements that define the order of execution, and allow assignment to variables. I have considerable doubts about whether this is the right way to go. There are use cases where such features are badly needed, but my fear, based on experience with saxon:assign, is that the facilities will be greatly abused by users who haven't taken the time it needs to learn about declarative programming. Also, Dana has a vision of XQuery being used to write entire applications. I prefer to think of XQuery being used to write small components, each of them functional in nature, which are then bound together to form a complete application using pipeline processing languages (which is where the sequential, stateful logic belongs).

I've now got a weekend to enjoy in Chicago, this being what happens when you pay your own air fares. Off to play croquet at 7.45 am - an unthinkable hour back home in England, but perhaps the idea is to avoid the heat and humidity. Even in free time, however, the diary is overloaded: I would have liked to watch the England v. Portugal match.