RE: [xml-dev] XML Schema: "Best used with the ______ tool"

["Michael Kay" <mike@saxonica.com>]

Running this from the Saxon command line, with the query as written, I get
the following results:

Query compile time: 161ms

Document parsing/build time: 125ms

Query execution time (average over 100 queries):
  age=1, gender=male: 12.5ms
  age=100, gender=male: 34.9ms

I wasn't sure what query parameters you were using.

The difference between the two queries is of course the volume of result
data; in my test I was serializing the results to a file rather than
consuming them in a Java application. But I did include the string
concatenation. Sending the results to a null destination (to show the impact
of the serialization cost) reduces the latter cost to 25.1ms.

Removing the string concatenation and just returning the nodes (without
serialization) reduces the query times to 12.3ms and 17.7ms respectively.

This is Saxon-B 9.1.0.3. Normally this kind of query would run significantly
faster in Saxon-SA, which would take advantage of indexing. However, this
example query is on fields (age and gender) that have so few distinct values
they seem deliberately chosen to make indexing ineffective. Also, this kind
of query would often benefit from document projection, but because the data
in the file is so artificially minimal, projection yields no benefits.

I haven't tried making the query schema-aware, but I did try modifying it to
do an integer comparison on age ($x/xs:integer(@age) < $age) and this
reduces the execution times marginally, to 12.0ms and 17.2ms respectively.

Now, it's not clear to me here what I'm comparing with. You reported a
figure of 0.09s for the data binding test: I assume that is 100 executions
of the query (with what parameters, though?) and excludes the XML
parsing/marshalling cost? What I would actually expect is that for both
technologies, the parsing cost (125ms in my case) is dominant in many
real-world situations. If the query execution cost turns out to be 12ms for
XQuery vs 0.9ms for data binding, then I think very few applications are
going to notice the difference. (Remember, I never said it would be faster:
I was challenging Dennis's assertion that XQuery performance was not good
enough to meet the user requirement.)

My machine is a Toshiba Tecra laptop, Intel Core 2 Duo, 2.40GHz running
Windows Vista; I used JDK 1.6.0_07 with the JDK-supplied Xerces parser.

Michael Kay
http://www.saxonica.com/ 


> While I would also like to see the results of comparing XSLT 
> to data binding as agreed between you and Dennis, I came up 
> with a simple Binding/XQuery benchmark for the above scenario 
> (repetitive access to most of the data in a document). It 
> compares the speed of performing the same operation using one 
> implementation of XML data binding (CodeSynthesis XSD[1]) and 
> one implementation of XQuery (XQilla[2]). The source code, 
> including the schema and sample XML document is available here:
> 
> http://www.codesynthesis.com/~boris/tmp/dbxq.tar.gz
> 
> The benchmark operates on the following XML:
> 
> <t:people xmlns:t='http://www.example.com/test'>
>   <description>People catalog.</description>
>   <person first="John" last="Doe" age="30" gender="male"/>
>   <person first="Jane" middle="Q" last="Doe" age="28" 
> gender="female"/>
> 
>   ...
> 
> <t:people>
> 
> The operation performed selects all the person records from 
> the catalog that are of a specific gender and younger than a 
> specific age. The input parameters (gender and max age) are 
> determined at runtime. The output is first name, last name, 
> and age for each matching record, expected as native types 
> (string, string, and unsigned short). If you need a concrete 
> example, think of it as a GUI or server application where the 
> user or client can specify gender and max age (in GUI or as a 
> non-XML request) and get the list of records back (again, in 
> GUI or as a non-XML response).
>