Browse Benchmarks
Benchmark ::FLWR-RETURN-CHILD-POSITION : 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) an increasing number of same-depth XML trees.
|
Result unit: |
Milliseconds |
| Query: |
|---|
|
The query used in this micro-benchmark returns the XML elements found in the input document at level 3, regardless of their names. The number of the returned elements is varied by using a positional predicate to select them.
For every integer n, the corresponding query, named FLWR-RETURN-CHILD-POSITION(n), is:
for $x in /t1/t2
return $x/*[position()<=n]
The purpose of this query is to simply test the performance of returning (copies of) deep data trees. To capture this, the navigation needed to locate the roots of the copied trees is kept very simple. On the document part of this micro-benchmark, all copied subtrees have about the same size.
The performance results recorded on this micro-benchmark could be compared with those obtained for the micro-benchmark FLWR-COPY-CHILD-POSITION, which targets exactly the same subtrees in the return clause, but returns them directly (without copying them). The performance differences between the two is likely due to the overhead of tree copying.
It should be noticed that in an environment where the result of FLWR-COPY-CHILD-POSITION is only needed under its serialized form (not as a "live" instance of the XQuery data model), one could optimize the execution of FLWR-COPY-CHILD-POSITION by avoiding to actually copy the subtrees prior to serializing them as children of the <res> element.
|
|
Syntax: |
|
|
Language: |
XQuery 1.0 |
|
Generator: |
generateQ25.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 |
|
|