Browse Benchmarks

Benchmark ::FLWR-COPY-DESCENDANT-NAME : Descendant axis navigation
(submitted at 2006-06-26T18:00:00)
Authors: Ioana Manolescu (Gemo Group, INRIA Futurs, France) Philippe Michiels (Universiteit Antwerpen, Belgium) Cédric Miachon (BD, LRI, Université Paris Sud 11, France)
Categories: XQuery,Query Scalability
Target: All systems
Engine type: persistent-storage main-memory streaming
Measure: The measure targets the total execution time of an XQuery query returning (copies of) XML elements scattered at all depths in the input document.
Result unit: Milliseconds

Query:

The query used in this micro-benchmark returns the XML elements found in the input document at any level greater than 2, and whose name belongs to a given node name set. The subtrees thus copied from the input document are returned as children of a single (constructed) XML element.

For every integer n, the corresponding query, named FLWR-COPY-DESCENDANT-NAME(n), is:
     
     for $x in /t1/t2
     return <res>{$x//t3, $x//t4, ..., $x//t(n+2)}</res>

The purpose of this query is to test the performance of arbitrary-depth navigation performed in a return clause, combined with the construction of large, deep trees. Query FLWR-COPY-DESCENDANT-NAME(n) navigates at random depth in the document, and returns all subtrees whose root is labeled

t3
,
t4
,...
t(n+2)
. This query stresses the system's capacity to perform multiple, potentially overlapping optional navigations, while at the same time returning large data volumes. Observe that the same input element may be copied several times in a given output element, if it appears in several subtrees copied by the return clause for a given set of bindings of the FOR variables. Thus, any single element returned by this query (and especially those returned for large
n
values) may be of significant size.

The size of a returned element, on average, increases as

n
increases.

Syntax:
Language: XQuery 1.0
Generator: generateQ23.java

Document:
The document flat2.xml is a tree such that:
  • the root is labeled t1
  • the root has 3268 children, labeled t2
  • each t2 child of the root (level 2 node) has 10 children, labeled with equal probability t3, t4, t5, ..., t12
  • each child of a t2 element (level 3 node) has 1 child, labeled with equal probability t3, t4, t5, ..., t12
  • ...
  • each level 12 node has 1 child, labeled with equal probability t3, t4, t5, ..., t12
  • each evel 13 element is a leaf.

More generally: the root has fanout 3268, the root's children have fanout 10 (bringing the number of nodes at level 2 to 32680), all elements whose level is between 2 and 12 have exactly one child, and the elements at level 13 have no children. (The document can be seen as a rooted collection of 32680 chains of parent-child elements, 10 deep.) At levels 3 to 13, node labels are uniformly distributed among t3, t4,..., t13.

The document's size is about 11 MB. The document is generated using the MemBeR document generator with the following configuration file:
Generator: MemBeR.Generator
Configuration file: Q21_exp_MemBeR_Generator_config.xml

Parameters:
Parameter n:
This is the number of consecutive child navigation steps in the query.
This parameter characterizes the: query
Unit: None.
Value Range: [ 1 .. 19 ]
Distribution: uniform
Scale: ordinal
Parameter docsize:
This is the size of the document.
This parameter characterizes the: doc
Unit: Byte
Values: 11009952
Distribution: uniform
Scale: ordinal

Methodology:
Running scenario: queryScale
Test the influence of the number of child steps on the total execution time. All other parameters are fixed.
Parameter instantiation:
Name Value(s)
n 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9
Download the micro-benchmark: [XML]
Micro-benchmark results