Low-latency XPath Query Evaluation on Multi-CoreProcessors

Ben KarsinInformation and Computer

Sciences Dept.University of Hawai‘i at Manoa1680 East-West Rd, Honolulu,

HI 96822, U.S.A.karsin@hawaii.edu

Henri CasanovaInformation and Computer

Sciences Dept.University of Hawai‘i at Manoa1680 East-West Rd, Honolulu,

HI 96822, U.S.A.henric@hawaii.edu

Lipyeow LimInformation and Computer

Sciences Dept.University of Hawai‘i at Manoa1680 East-West Rd, Honolulu,

HI 96822, U.S.A.lipyeow@hawaii.edu

ABSTRACTXML and the XPath querying language have become ubiq-uitous data and querying standards used in many industrialsettings and across the World-Wide Web. The high latencyof XPath queries over large XML databases remains a prob-lem for many applications. While this latency could be re-duced by parallel execution, issues such as work partitioning,memory contention, and load imbalance may diminish thebenefits of parallelization. We propose three parallel XPathquery engines: Static Work Partitioning, Work Queue, andProducer-Consumer-Hybrid. All three engines attempt tosolve the issue of load imbalance while minimizing sequen-tial execution time and overhead. We analyze their per-formance on sets of synthetic and real-world datasets. Re-sults obtained on two multi-core platforms show that whileload-balancing is easily achieved for most synthetic datasets,real-world datasets prove more challenging. Nevertheless,our Producer-Consumer-Hybrid query engine achieves goodresults across the board (speedup up to 6.31 on an 8-coreplatform).

1. INTRODUCTIONXML (eXtensible Markup Language) has become ubiqui-

tous in a variety of industry messaging and data standards,particularly within the context of the World-Wide Web. Itis one of the most widely-used formats for sharing struc-tured data and has become ingrained in the technology ofthe Web. XML is most-commonly used for communicationof data, though many applications utilize it to store and an-alyze large amounts of data as well (e.g., DBLP [12]). Thehierarchical nature of XML data makes it well-suited forcertain applications, though the latency of XPath[7] queryevaluation remains a limiting factor. Web-based applica-tions that utilize XML for data store can experience sig-nificant performance issues due to this query latency. AsXML datasets becoming increasingly large, the problem ofsingle-query latency becomes more significant.

The increasing number of processing cores on moderncommodity multi-core systems represents an opportunityfor reducing the latency of XPath query processing. Moststate-of-the-art XPath processing libraries, such as ApacheXalan [23], leverage multi-core architectures through theconcurrent execution of multiple XPath queries: multiplethreads each evaluating a different XPath query simultane-ously. Although the overall throughput is increased, thereis no improvement in query latency because each query is

executed sequentially. Concurrent evaluation of multipleXPath queries can actually increase individual query laten-cies due to sharing of hardware resources (caches, memorybus). Previous work on parallel evaluation of XPath querieson multi-core architectures have used a static partitioningof the query evaluation task and a fixed assignment of parti-tions to cores in order to achieve significant speedups onwell-behaved datasets and queries [4, 3]. However, suchstatic approaches are unlikely to work well when the par-titions are unbalanced in the amount of work they contain.

In this work we study the parallelization of XPath queryevaluation with the goal of reducing the latency of a sin-gle XPath query over an in-memory XML Document Ob-ject Model (DOM) tree on multi-core architectures. Thiswork focuses on single-query latency because, for web-basedapplications, this latency can severely degrade performancefor end-users. Parallelization is achieved by partitioning thequery evaluation into work units, i.e., XML tree nodes thatcan be evaluated independently

We investigate three strategies: (i) Static Work Parti-tion (SWP), (ii) Work Queue (WQ), and (iii) Producer-Consumer-Hybrid (PCH). SWP is a straightforward approachused in previous work [4, 3] in which work units are assignedto threads statically before the onset of concurrent compu-tation. Because it uses static work partitioning, SWP canlead to poor load balance if query processing is more com-putationally intensive for some sub-trees than some others.With WQ, work units are placed in a thread-safe sharedworkqueue. Threads retrieve work units from the workqueueand evaluate them dynamically, which improves load balancewhen compared to SWP but comes with additional overheadfor ensuring thread-safety of the workqueue. Both SWP andWQ correspond to well-known parallelization strategies thathave been used in countless parallelization contexts. An-other such well-known strategy is the producer consumerapproach in which threads can either produce work unitsinto or consume work units from a shared workqueue. Wegeneralize the producer consumer approach and develop thePCH strategy in which can also be a “hybrid”: it can playthe role of both consumer and producer. Given n threads,PCH allows any combination of p producers, c consumers,and h hybrids, where p + c + h = n, thus widening thedesign space compared to the standard producer consumerapproach. This paper presents the PCH strategy and anempirical study of all three SWP, WQ, and PCH strategies,making the following contributions:

• We implement a custom sequential query engine andan accompanying performance model that serve as basesfor developing parallel query engines and assessing theirperformance.

• We implement query engines that parallelize the exe-cution of a single XPath query on multi-core platformsusing the SWP, WQ, and PCH strategies. While SWPand WQ are standard approaches, PCH is a novel gen-eralization of the producer consumer model.

• We evaluate our query engines with synthetic bench-marks, a popular XML benchmark (XMark), and areal-world XML dataset (DBLP).

• We find that all of our parallel query engines can achievesome speedup, with PCH achieving near-linear speedupfor most synthetic datasets and queries, and signifi-cant speedup for most queries on real-world and bench-mark datasets. The good performance of PCH is ex-plained by the use of hybrid threads that can be usedto improve upon the traditional producer consumer ap-proach.

• We find that some queries over the DBLP dataset areparticularly difficult to parallelize, and we identify theroot causes of poor parallel performance. Some ofthese causes can be addressed by modifying our par-allelization approach. Others are inherent to queryingXML DOM trees and would require modifying the doc-ument order to achieve good parallel speedup.

The remainder of this paper is organized as follows. Sec-tion 2 discusses related work. Section 3 states the problemof query parallelization. Section 4 describes our baselinesequential XPath query engine and a simple performancemodel. Section 5 details our three parallel XPath query en-gines. Their performance is evaluated on synthetic datasetsin Section 6 and on real-world and benchmark datasets inSection 7. Finally, Section 8 summarizes our results andhighlights future work directions.

2. RELATED WORKThe field of XML processing is prolific, with many stud-

ies focusing on both analytic and empirical aspects. Sev-eral areas have been studied extensively and are related butoften orthogonal to our work. The problem of XML car-dinality and selectivity estimation is one such area [2, 20,5, 22, 13, 14]. Incorporating estimation techniques in ourmethods could yield performance improvements, but it isbeyond the scope of this paper. Another area of XML pro-cessing that has been extensively studied is that of embed-ded XML processing and hybrid XML/relational systems.This area has been a hotbed in recent years (see severalbroad surveys [9, 10, 17, 1]). The recent focus has beenon comparing and integrating native XML query processingwith embedded XML in relational systems. The work in [9]compares these two approaches (and integration), applied tothe problem of twig pattern matching. Our work could alsobe applied to pattern matching, but in this paper we onlyattempt to leverage multi-core hardware for native XMLquery processing. The work in [10] focuses on XED (em-bedded databases) versus NED (native databases) and rele-vant query optimization techniques. Moro et al. [17] provide

a broader overview of the entire field, with discussions onmany topics including query processing, views, and schemaevolution. Schwentick [1] provides a more analytic study,focusing on automata capable of processing XML trees effi-ciently. While some of the ideas pertaining to tree process-ing are relevant for our work, this paper provides a moreempirical study of parallel XPath query execution.

Several authors have studied multi-query processing onXML databases in recent years [21, 24, 6]. These studies aimto improve query throughput on XML databases by leverag-ing parallel hardware architectures. Wang et al. [21] utilizea range of methods to increase throughput when evaluat-ing multiple queries over a compressed XML dataset. Thework in [24] incorporates large numbers of queries into asingle NFA (Non-deterministic Finite Automata), which isthen fragmented to enable parallelization. Results show sig-nificant throughput improvement. Our work differs becausewe focus on reducing the latency of a single query. Cong etal. [6] aim to increase query throughput as well as reducequery latency. The proposed approach consists in decom-posing XPath queries into several smaller sub-queries forparallel execution and then merge query results. The au-thors describe parallelization methods for XPath queries onboth cluster and multi-core platforms. They obtain signifi-cant speedup using all methods, though there are concernsabout redundant processing of query nodes. Query decom-position results in several smaller sub-queries, causing thepossibility of duplicate processing on portions of each sub-query. Additionally, the process of merging results of sub-queries can be computationally costly, especially if there aremany query matches. Our approach avoids these problemsby implementing intra-query parallelism through distribu-tion of XML document tree nodes to processor cores. Thework in [15] improves the performance of XML serializationthrough parallel processing of XML DOM structures. Theauthors use work-stealing to balance work among threads,with region-based query partitioning to improve scalability.While their approach successfully achieves parallel speedup,it is limited to XML serialization. Furthermore, results areonly provided for a single 4-core platform and for one rela-tively small (25MB) dataset. Our work aims at paralleliza-tion of general XPath queries on XML DOM tree structures,with results presented for 4- and 8-core platforms on a rangeof synthetic and real-world datasets (up to 1GB in size).

Some of the work in this paper builds on [3] and [4].The work in [3] gives an overview of the problem of par-allelization of XPath queries and presents preliminary ex-perimental results obtained with the Xalan query engine.The work in [4] compares XPath parallelization results us-ing three static work partitioning techniques (data, query,and hybrid partitioning), with arguably limited success. Inthis work we extend the work in [3, 4] by developing andevaluating parallel query engines that utilize more sophisti-cated and dynamic work partitioning approaches to achievedrastically more efficient parallelization.

3. PROBLEM STATEMENTWe address the problem of low-latency evaluation of XPath

queries over XML data using multi-core processors. XMLdata is assumed to be parsed into an in-memory DOM tree [8].In principle, a SAX (Simple API for XML) [18] parser canbe used to evaluate XPath queries directly on XML datafiles; however, DOM is more efficient for repeatedly execut-

ing multiple queries on a single XML document. The DOMapproach is more well-suited for web applications in particu-lar, where servers typically repeatedly execute queries on thesame XML dataset. One limitation of the DOM approach isthat it is required to preserve document order of the XMLelements; hence, certain efficient tree-traversal methods thatdo not preserve document order cannot be applied and areexcluded from consideration in this paper. A DOM tree is arooted tree where XML elements are represented as nodes,and the nesting of XML elements are represented as edges.Each node is associated with an element name or a tag whichis not unique and can be a string of arbitrary length. TheXPath standard allows for arbitrarily complex queries, e.g.,queries decorated with predicates, but in the context of thispaper we consider simple rooted XPath queries defined by asequence of tags often written as /t1/t2/ . . . /tk. A DOMtree node is said to be a match node if the sequence ofnode tags of the path from the root to the node in ques-tion matches the XPath query exactly. The result set of anXPath query is the set of all ‘matching nodes’. Given anXPath query, a DOM tree node is called a sub-match nodeif it is a match node for a prefix of the XPath query. Thesequential XPath evaluation problem takes an in-memoryDOM tree tree and a simple rooted XPath query as inputand returns the set of all matching nodes as efficiently as pos-sible using a single thread of execution. The parallel XPathevaluation problem takes an in-memory DOM tree tree anda simple rooted XPath query as input and returns the set ofall matching nodes as efficiently as possible using multiple(possibly parallel) threads of execution on a multi-core pro-cessor. The next section describes our analysis of a solutionto the sequential XPath evaluation problem that is used asthe baseline for the parallel version. The following sectionthen presents our solution to the parallel XPath evaluationproblem.

4. SEQUENTIAL XPATH QUERY ENGINE

4.1 Custom Query EngineSome XPath query engines, such as Apache Xalan, utilize

additional indexing data structures to support more efficientnavigation of the XML DOM tree for certain types of traver-sals. While this provides improved performance for somequeries, it creates unpredictability when analyzing the over-all performance of the query engines especially in a parallelcontext. Our initial experiments with the parallelization ofXalan produced inconsistent results. Table 1 shows parallelquery evaluation times in seconds, averaged over 100 trialsusing a binary XML tree and a query resulting in every leafnode being a match node. These results are obtained onGreenwolf, the 4-core platform described in Table 2. As ex-plained in more detail in later sections, a simple approachfor parallelizing an XPath query is to first use a sequentialphase that traverses the XML tree down to some predefineddepth, which we call the context depth. This traversal leadsto N sub-match nodes at that depth, and these nodes canthen be evaluated in parallel by P threads on P cores, eachthread evaluating N/P nodes. The context depth is thus akey driver of parallel query evaluation time. Another suchdriver is the tag length, since longer tags imply more timeconsuming tag comparisons. The left-hand side of Table 1show results obtained with Xalan as the basis for the simpleparallelization described above. We see that with a context

Xalan (sec.) Custom (sec.)Tag ↓ / Context → 2 4 6 2 4 61 54.25 0.16 28.77 0.26 0.17 0.172 65.54 0.16 26.76 0.28 0.19 0.174 65.41 0.16 26.95 0.30 0.20 0.188 64.90 0.29 29.19 0.35 0.23 0.2016 55.02 0.36 28.01 0.44 0.29 0.2532 66.05 0.25 28.71 0.58 0.39 0.3364 57.99 0.28 27.02 0.85 0.57 0.49128 66.45 0.27 29.49 1.34 0.89 0.77256 59.66 0.36 28.28 2.37 1.58 1.35512 57.25 0.32 27.04 4.23 2.82 2.421024 54.97 0.31 27.77 7.61 5.07 4.35

Table 1: Custom vs. Xalan parallel runtimes using an all-match query on a 20 level deep binary tree with 4 threadson Greenwolf. Varying context depth has a large and un-predictable impact on Xalan performance, while tag lengthdoes not.

depth of 2 or 6 the query time is very large above 50 sec or 25sec, respectively, even though it is below 1 sec for a contextdepth of 4. While one may expect that there would be anoptimal context depth, such drastic differences are difficultto explain. Furthermore, the query time is not necessarilymonotonically increasing with the tag length. Other resultsnot presented here show that the query times are not alwaysreproducible. We conclude that Xalan likely utilizes index-ing data structures that have complex effects on the querytime. As a result, Xalan is not a viable target for this work.

Since our goal is to study the parallelization of XPathqueries on an in-memory DOM tree, and given the resultsobtained with Xalan, we opt to develop our own sequentialquery engine to form the basis for our parallel query engines.Our custom query engine recursively traverses the XML doc-ument tree, comparing the XML tag of each traversed nodewith the XPath query string of the corresponding depth. Ifthe comparison succeeds, the nodes’ children are evaluatedrecursively (recall that such a node is called a sub-matchnode). When a node is found with a tag matching the finalstring of the XPath query at the query depth, it is saved asa match node. The right-hand side of Table 1 shows resultsobtained for the same parallel query engine as above butusing our custom sequential query engine as a basis insteadof Xalan. The results show stable trends, with increasingquery times as the tag length increase, and comparable re-sults across different context depths.

4.2 Performance ModelGiven an XML tree and an XPath query, our goal is to de-

rive a closed form formula to estimate the performance of ourcustom sequential query engine. We achieve this by averag-ing attributes of individual nodes over the entire XML treeand measuring single-node computation times on the givenhardware. The result is a performance estimate based on theXML tree, XPath query, and hardware environment. How-ever, due to limited space, we provide only a brief overviewof our sequential performance model in this paper. We directinterested readers to [11] for a full derivation and analysis.In short, the performance model relies on the following pa-rameters:

• Tree Height (H): The maximum depth of the XMLtree;

• Branch Factor (B): The number of children per non-leaf node;

• Tag Length (L): The number of characters per querytag;

• Query Depth (D ≤ H): The maximum depth of thequery; and

• Selectivity (S): The number of (sub-)match childrenper non-leaf node.

• τ : The time to compare a single character of a node tagto a single character of a query tag, so that comparingtwo tags of L characters takes at most τ × L seconds;and

• α: The time to perform all processing of a single nodebesides tag comparison (e.g., pointer chasing).

Using these parameters and counting the average numberof nodes evaluated, we obtain the following formula for oursequential performance model:

Tseq = [B(SD−1 − 1)

S − 1+ 1]× (τ × L + α).

To enable accurate performance estimation, we execute sev-eral benchmarks to measure α and τ given a particular hard-ware platform. More specifically, we consider two platforms,Greenwolf and DiRT, described in Table 2 and used in dedi-cated mode for all experiments. By measuring query execu-tion time on each environment for a range of synthetic datasets, we empirically measure τ and α. To conserve space, weomit the details and direct the reader to [11] for full details.With empirical values for τ and α, we are able to estimatethe execution time of any query using the parameters de-scribed above.

Environment Name Proc. Cores Proc. TypeGreenwolf 4 Intel Core i7 2.67 GHz

DiRT 8 Intel Xeon 2.40 GHz

Table 2: Overview of the 2 hardware environments used forexperimentation.

4.3 Query Engine and Performance Model Val-idation

In this section we validate both our query engine im-plementation and our instantiated performance model bycomparing actual query processing times to analytical es-timates. We perform experiments for a set of syntheticdatasets (XML trees and queries), i.e., for various valuesof the D, B, L, and S parameters. We define a notationfor our synthetic datasets based on these parameters. Eachdataset comprises an XML tree and a query for that tree,and the query depth (D) is equal to the tree depth (H).We use a Dw Bx Ly Sz notation to describe the query/treedepth, the branching factor, the tag length, and the selectiv-ity for a given dataset. For example, D20 B2 L16 S1 denotes

Figure 1: Average query runtime vs. S (Selectivity) onGreenwolf and DiRT. Results shown for D6 B20 L1 and D4B150 L1 synthetic experiments. All initial results indicatethat our custom query engine performs closely in-line withour performance estimates.

a 20-level deep binary tree with 16-character tags and a 20-level deep query that matches 1 child at each tree node. Allgenerated trees are complete, and (sub-)match children areselected among a non-leaf node’s children using a uniformprobability distribution. Each run of a query engine for anexperimental scenario is repeated 100 times. The average isreported and error bars are displayed on all graphs (oftenthey are so small that they cannot be seen).

Figure 1 shows the results of one set of experiments andthe corresponding performance estimates on DiRT. Due tolack of space, we omit further results of the other experi-ments, though we find that estimates are relatively accurate(relative error rates under %10) with respect to actual queryevaluation times and they exhibit the same trends. For thisparticular experiment, we obtained an average error of %3.5.We conclude that our custom query engine performs as ex-pected, that our performance model can be used to estimatequery evaluation times, and that our query engine can serveas a viable baseline for developing parallel query engines.

5. PARALLEL XPATH QUERY ENGINESIn this section, we introduce our three parallel XPath

query engines: Static Work Partitioning (SWP), Work Queue(WQ), and Producer-Consumer-Hybrid (PCH). SWP andWQ are based on the same two-phase approached describedbelow, but they differ in how they implement the secondphase leading to various trade-offs between load-balance andoverhead. All three parallel engines use the custom sequen-tial query engine described in Section 4.1 as a basis.

A simple approach for parallelizing our sequential queryengine is to use two phases:

• Sequential Phase – Execution of the query to depth C,the context depth, generating a set of sub-match nodes.These nodes, which we call the context nodes, can beevaluated independently.

• Parallel Phase – Parallel evaluation of the context nodesby N threads on N cores.

5.1 Static Work Partitioning (SWP)SWP uses a static work distribution. After the sequential

phase, the context nodes are partitioned into N “blocks”as evenly as possible, and each block is assigned to a threadfor evaluation. Figure 2 shows an example work distribution

Figure 2: Example allocation of work distributed among 8threads for each level of a 1024-node XML tree using SWP.

across eight cores using SWP on a small 1024-node syntheticdataset (D11 B2 L1 S2, see Section 4.3 for details on oursynthetic datasets). This figure is generated from an actualquery execution on an 8-core platform during which eachnode was labelled by the index of the thread that evaluatedit. These nodes are displayed in the figure based on theirlocation in the document tree, and the top C = 6 levelscorrespond to the context nodes.

SWP is designed to minimize runtime overhead, and it canachieve good load-balancing, as seen for instance in Figure 2.However, several factors can degrade its performance. First,the sequential context computation limits overall parallelspeedup (Amdahl’s law). Second, if the context nodes arenot evenly divisible by the number of processor cores, somecores will inevitably have more work. Third, if some contextnodes are more computationally intensive than others (e.g.,they have more children, they have more sub-match chil-dren), load balance will be poor and so will be the parallelspeedup. For these reasons, we view SWP as a baseline ap-proach that is simple, low-overhead (no shared state amongthreads and thus no synchronization necessary), but that isnot expected to achieve high speedup in practice.

5.2 Work Queue (WQ)WQ employs a simple workqueue to attempt to avoid load

imbalance and improve parallel performance. The goal is todistribute work among threads more evenly by dynamicallyassigning work to idle threads. Once the context depth Cis reached through sequential execution, the context nodesare divided into W work units and placed in a shared, i.e.,thread-safe, workqueue data structure. The N threads thenbegin parallel execution, each reading a work unit from thequeue, processing it, and returning to the workqueue formore work. Once the workqueue is empty and all threadsfinish, the query is complete. The use of a shared thread-safeworkqueue increases overhead. Figure 3 is similar to Figure 2and shows an example work allocation across 8 threads usingWQ with W = 16 for the same small synthetic dataset.

Parameters W and C determine the size and the num-ber of the work units read from the workqueue. Throughempirical testing, we determine that good values of C andW can be easily found. We find that we can achieve goodperformance with small values of C and W , but we omitthe details due to limited space and direct interested read-ers to [11]. For all further experiments with SWP and WQ,we use C = 3 and W = 16.

5.3 Producer-Consumer-Hybrid (PCH)PCH extends the well-known producer-consumer model to

evaluate XPath queries in parallel using a novel parallel ex-

Figure 3: Example allocation of work distributed among 8threads for each level of a 1024-node XML tree using WQ.

ecution model. Unlike SWP and WQ, PCH does not requirea sequential phase to compute context nodes. Instead, par-allel execution can begin as early as possible (i.e., once theroot node has been processed). By Amdahl’s law we knowthat reducing the amount of sequential computation even bya small amount can lead to large improvements in speedup.We define three types of threads that share a thread-safeworkqueue of work units and can be mixed to achieve var-ious trade-offs between load imbalance and overhead. Anoverview of these thread types and their corresponding ac-tivities is:

• Producer – given one tree node, evaluates all childrenof this node and writes those children that are sub-match nodes to the shared workqueue;

• Consumer – reads a tree node from the shared workqueue,recursively evaluates all its children nodes and addmatch nodes to the query results, repeats; and

• Hybrid – reads a tree node from the shared workqueue,recursively evaluates all its children nodes, recursingonly up to Rdepth times, writes sub-match nodes backto the shared workqueue and adds match nodes to thequery results, repeats.

The next three sections give details on the algorithms usedby each type of thread above as well as relevant implemen-tation details.

5.3.1 Producer ThreadsProducer threads are designed to recurse only once given

a tree node and write sub-match nodes to the workqueue sothat these nodes can be processed by Consumer or Hybridthreads. Consequently, producer threads never read fromthe workqueue. One difficulty with this approach is that it isvery likely that a producer threads would become idle earlyin the query evaluation process. To address this problem,producer threads do not write back to the workqueue allof the sub-match nodes they have identified. Instead, theykeep a small number of sub-match nodes for themselves. Weuse Nkeep to denote this number of sub-match nodes. Thesekept nodes are used to continue execution once all nodes inthe set of nodes initially assigned to the producer have beenevaluated. We find that any small value (between 2 and10) for Nkeep results in good performance. Due to limitedspace, we omit the details of this experimentation and directinterested readers to [11]. We utilize Nkeep = 5 for furtherexperimentation.

The pseudo-code for a producer thread is shown in Algo-rithm 1. This pseudo-code assumes that a “list of nodes”

function producer(query, nodes)begin

results← ∅workingList← {nodes}while workingList 6= ∅ do

n = workingList.removeF irst()toWrite← ∅foreach child in n.children do

if child.tag = query.tags[child.depth] thenif child.depth < MaxDepth then

toWrite.append(child)else

results.append(child)end

end

endtoKeep = toWrite.removeF irstN(Nkeep)workingList.append(toKeep)sharedQueue.append(toWrite)

endreturn results

endAlgorithm 1: Pseudo-code of Producer threads in PCHquery engines. These pure producer threads never readfrom the shared queue. To prevent starvation, they alwayskeep Nkeep elements.

abstract data type is available, with usual removeFirst, re-moveFirstN, and append operations to remove and returnthe first node from a list, remove the first N nodes of a listand return them as a list, and append a node or a list tothe end of a list. Although implicit in all our pseudo-code,all operations on the shared workqueue are enforced to beatomic by using a single lock. All our implementations usea spinlock so as to reduce locking overhead.

5.3.2 Consumer ThreadsLike producers, consumer threads have limited interac-

tion with the shared workqueue. While producers neverread from the workqueue, consumers threads (pseudo-codein Algorithm 2) never write to the queue. They perform astandard tree traversal for whatever node(s) they are given.Consequently, load-balancing is achieved solely by the useof producer and/or hybrid threads. For instance, if a con-sumer thread happens to be given the root node of the doc-ument tree, it will evaluate the entire query itself and allother threads will remain idle. To prevent this worst-casescenario from occurring, our implementation insures that allproducer and hybrid threads receive work, i.e., nodes to eval-uate, before any consumer thread reads from the workqueue.

5.3.3 Hybrid ThreadsAs seen in the pseudo-code in Algorithm 3, hybrid threads

incorporate features from both consumer, i.e., reading fromthe shared queue and recursing, and producers, i.e., writingsub-match nodes to the shared queue. The Rdepth parame-ter controls the number of times hybrid threads will recursebefore writing to the shared queue. If Rdepth = 0, hybridsare producers, although they read when they run out ofwork to do. If Rdepth = D, hybrids are consumers and neverwrite back to the workqueue. Through experimentation wefind that performance is not greatly impacted by Rdepth, aslong as it is close to D/2. Due to limited space, we omitthe details of these experiments and utilize D/2 for furtherexperimentation with PCH.

function consumer(query)begin

results← ∅while sharedQueue 6= ∅ do

n← sharedQueue.removeF irst()consumerRecurse(n, query, results)

endreturn results

end

function consumerRecurse(n, query, results)begin

foreach child in n.children doif child.tag = query.tag[child.depth] then

if child.depth < MaxDepth thenconsumerRecurse(child, query, results)

elseresults.append(child)

endend

end

endAlgorithm 2: Pseudo-code of Consumer threads in PCHquery engines. Being pure consumers, they never write tothe shared queue.

5.3.4 PCH Thread MixDue to differences between each thread type and their po-

tentially complex interactions, PCH corresponds to a classof query engines. We use the PCH-p/c/h notation to denotean instance of PCH with p producer threads, c consumerthreads, and h hybrid threads (e.g., PCH-3/4/1 would bethree producers, four consumers, and one hybrid). A chal-lenge with PCH is determining the best mix of producer,consumer, and hybrid threads. As might be expected, thebest mix depends on the dataset, the query, and the hard-ware.

Figure 4 shows how work is distributed by three differentPCH instances on a small 1024-node synthetic dataset onan 8-core platform. Not surprisingly, the numbers of pro-ducer, consumer, and hybrid threads greatly affects workdistribution. In Figure 4a we see that load-balancing is poorsince only 1 producer thread (in this case configured withNkeep = 1) is available. The first node placed on the workqueue requires a large amount of of work, causing the firstconsumer thread to be assigned much more work than theother consumers. Adding a second producer thread, shownin Figure 4b, greatly improves load-balancing by further par-titioning the work. By adding the second producer thread,we increase the maximum possible speedup from 2 to 4.Figure 4c is the most extreme case of work partitioning, withall 8 threads as hybrids (Rdepth = 0 in this example). We seethat the entire tree is segmented and threads all have seem-ingly random partitions. While such an execution providesgood load balance, it comes at the price of high overhead dueto constant thread interactions with the shared workqueue.

6. PARALLEL QUERY ENGINE EVALUA-TION

In this section, we first define a lower bound on parallelexecution time using our performance estimate from Sec-tion 4.2. We then present results for a series of syntheticexperimental scenarios, determining how each query engineis impacted by dataset-specific and query-specific features.

(a) PCH-1/7/0 (1 Producer, 7 Con-sumers)

(b) PCH-2/6/0 (2 Producers, 6 Con-sumers)

(c) PCH-0-0-8 (8 Hybrids)

Figure 4: Example allocation of work to 8 threads for each level of a 1024-node XML tree when using PCH on an 8-coreplatform (results obtained by executing a query in which all leaf nodes are match nodes).

function hybrid(query)begin

results← ∅while sharedQueue 6= ∅ do

n← sharedQueue.removeF irst()toWrite← hybridRecurse(n, query, Rdepth, results)sharedQueue.append(toWrite)

endreturn results

end

function hybridRecurse(n, query, Rdepth, results)begin

toWrite← ∅foreach child in n.children do

if child.tag = query.tag[child.depth] thenif child.depth < MaxDepth then

if Rdepth > 0 thenhybridRecurse(child, query, Rdepth − 1,results);

elsetoWrite.append(child)

end

elseresults.append(child)

endend

endreturn toWrite

endAlgorithm 3: Pseudo-code of Hybrid threads in PCHquery engines. Hybrids combine the functions of both pro-ducer and consumer threads, with the Rdepth parameterdictating the frequency of writes to the shared queue.

6.1 Performance BoundsIn Section 4.2 we presented a performance model that

accurately estimates the average execution time of a givenquery on a given hardware platform. It uses a series of data-, query-, and hardware-specific parameters and was seen toaccurately estimate the performance of our sequential queryengine on a series of synthetic experiments. Using our se-quential performance model as a basis, we can define a sim-ple estimate of a lower bound on parallel query executiontime, Tbound, as:

Tbound =Tseq

P

where Tseq is the sequential performance estimate from Sec-tion 4.2, and P is the number of threads/cores. This lowerbound ignores all parallelization overhead and assumes a

Figure 5: Average query runtime on DiRT vs. L (tag length).Results shown for the D4 B100 S100 synthetic experiments.All query engines achieve good parallel speedup, with thebest parallel performance obtained using PCH (speedup of5.92 using PCH-2/1/5).

perfect parallel speedup of P when using P cores. Tbounds

is based on Tseq, and Tseq is only an estimate of sequen-tial query evaluation time. Therefore, Tbound is not a lowerbound in the theoretical sense of the term. Nevertheless, ourresults show that Tbound is meaningful to assess the absoluteperformance of our parallel query engines.

6.2 Validation ExperimentsTo initially measure the performance of our parallel query

engines, we perform a range of synthetic experiments varyingeach of our query- and data-specific parameters (defined inSection 4.3). We measure the speedup of each parallel queryengine and compare results with our parallel lower-bounds.Note that the SWP and WQ engines cannot achieve per-fect parallel speedup, as they have a sequential computationphase. The PCH query engine does not use a sequentialphase, and thus could conceivably achieve linear speedup.

Figure 5 shows one among many sets of (similar) resultsfor a particular synthetic dataset and query (D4 B100 S100)for varying tag length (L) on DiRT. As expected all curvesgrow roughly linearly as L increases. The results of sequen-tial execution indicate that our query engine exhibits pre-dictable results, with an average deviation from the sequen-tial query time estimate of 3.1% for this experiment. Ourthree parallel query engines achieve good parallel speedup,with a maximum value for SWP, WQ, and PCH of 4.10,4.15, and 5.86, respectively, out of an absolute maximumof 8. We use PCH-2/1/5 for these experiments, which wefound to perform well for synthetic datasets. Similar resultsare obtained for other experiments on both Greenwolf andDiRT. In all of these experiments PCH achieves significantly

Figure 6: Speedup achieved by PCH for every p/c/h com-bination for D13 B4 synthetic test on DiRT. PCH-2/1/5achieves the best speedup.

better performance than SWP and WQ, close to the lowerbound estimate.

6.3 Query engine parameter configurationEach of our parallel query engines has a distinct set of pa-

rameters that define its behavior. In this section we presentresults from experiments used to measure the impact of theseparameters, making it possible to determine good parametervalues for each query engine for a given dataset/query on agiven hardware platform. Due to limited space, we omit thedetails of several of these parameters and direct interestedreaders to [11] for full details.

6.3.1 Numbers of Producers, Consumers, and Hy-brids

We evaluate the performance of different PCH-p/c/h in-stances via a series of experiments with synthetic datasets.In each experiment we measure average query executiontime using every possible p/c/h combination, from 1/1/0to 0/0/N , where N is the number of threads. We counta hybrid thread as both a producer and consumer, so thatPCH-N/N/0 is actually PCH-0/0/N (i.e., all threads areboth producers and consumers). Figures 6 and 7 show theparallel speedup achieved for each P/C/H combination onDiRT for two different synthetic experiments. Each experi-ment has similar tag length and selectivity and correspondsto a document tree with a similar number of nodes but withdifferent depth and width (D13 B4 and D24 B23). In thisfigure, all data points above the anti-diagonal correspondto cases in which at least one hybrid thread is used (withthe upper-right corner corresponding to an all-hybrid queryengine).

We see from Figures 6 and 7 that significant parallel speedupis achieved with a range of combinations. The best parame-ter configuration is PCH-2/1/5 for both of these tests. Themaximum speedup achieved in Figures 6 and 7 are 5.69 and5.62, respectively. In all of our synthetic experiments, PCH-2/1/5 is never more than %10 slower than the fastest con-figuration and performs better than other configurations inmost cases. We see similar results with the 4-core Greenwolfenvironment, with a maximum speedup using PCH-1/0/3 of3.06 and 3.13, respectively.

The results, overall, indicate that the load-balancing ben-efits of hybrid threads lead to performance improvementswhen compared to a standard producer-consumer approach.However, the all-hybrid configuration exhibits poorer perfor-mance, indicating that over-utilizing hybrid threads makesthe shared workqueue a bottleneck. Note that these experi-ments are for complete and balanced trees and queries. We

Figure 7: Speedup achieved by PCH for every p/c/h com-bination for D24 B2 synthetic test on DiRT. PCH-2/1/5achieves the best speedup.

expect that the best PCH-p/c/h combination may differ forreal-world datasets.

7. REAL-WORLD DATASETS AND QUERIESThus far in this paper we have evaluated the performance

of our three parallel query engines on a range of syntheticdatasets and queries and verified the results with analyticalperformance estimates. We determined that all three en-gines perform well on balanced, snythetic trees. Thus farfor all of our experiments, the best performance has beenobtained with PCH-2/1/5 and PCH-1/0/3 for DiRT andGreenwolf, respectively. In this section, we evaluate theperformance of our parallel query engines using real-worlddatasets and benchmarks, with the experimental methodol-ogy described in Section 4.3. We report experimental re-sults for the DBLP [12] and XMark [19] datasets. For eachdataset, we select and run several queries that traverse dif-ferent portions of the XML document tree and have differ-ent characteristics (different values of D, S, and L). Unlikesynthetic datasets used thus far, real-world data sets tendto have widely varying values for these characteristics, espe-cially across different levels of the XML document tree. Inall that follows we abandon the use of our analytical queryevaluation time estimate because it assumes that all levels inthe trees have identical branching factors and selectivities.

7.1 Experiments on DBLPThe DBLP [12] dataset is a 900MB XML file with nearly

25 million lines. The structure of the XML file, when parsedand loaded into memory, results in a very shallow (H =2) tree with widely varying branch factor. The root node(depth 0) has approximately B = 2.7 million children, yet at

Figure 8: Parallel speedup achieved by PCH when runningQ2dblp on the DBLP dataset using varying p/c/h combina-tions, on DiRT. The pattern indicates that, as with previousexperiments, the best combination is for PCH-2/1/5, witha maximum speedup of 3.08

.

Query ID Query String Depth Match Nodes

DB

LP

Q1dblp /dblp/incollection/cite 3 736Q2dblp /dblp/article/author 3 1782468Q3dblp /dblp/mastersthesis/* 3 50Q4dblp /dblp/book/cite 3 3319Q5dblp /dblp/inproceedings/pages 3 949501Q6dblp /dblp/www/title 3 1008156

XM

ark

Q1xmark /site/open auctions/open auction/ 5 59486 × scalingbidder/increase

Q2xmark /site/people/person/name 4 25500 × scalingQ3xmark /site/people/person/profile/interest 5 37688 × scalingQ4xmark /site/closed auctions/closed auction/ 8 6799 × scaling

annotation/description/parlist/listitem/text

Table 3: Queries on real-world data sets. For XMark each query is run on several differently scaled datasets, each returninga different number of query matches.

Runtime in seconds and (speedup) on DiRTQuery Seq. SWP WQ PCHQ1dblp 1.94 (1) 1.64 (1.18) 1.82 (1.06) 1.21 (1.60)Q2dblp 3.94 (1) 3.05 (1.29) 2.85 (1.38) 1.28 (3.08)Q3dblp 1.22 (1) 1.36 (0.90) 1.40 (0.87) 1.22 (1.00)Q4dblp 1.20 (1) 1.31 (0.92) 1.35 (0.89) 1.24 (0.97)Q5dblp 5.12 (1) 5.58 (0.92) 5.64 (0.91) 1.78 (2.87)Q6dblp 2.73 (1) 1.80 (1.52) 1.79 (1.53) 1.42 (1.92)

Runtime in seconds and (speedup) on GreenwolfQuery Seq. SWP WQ PCHQ1dblp 1.37 (1) 1.29 (1.06) 1.23 (1.11) 1.20 (1.14)Q2dblp 5.17 (1) 2.67 (1.94) 2.61 (1.98) 1.66 (3.11)Q3dblp 1.31 (1) 1.37 (0.96) 1.41 (0.93) 1.27 (1.03)Q4dblp 1.25 (1) 1.22 (1.02) 1.35 (0.93) 1.11 (1.13)Q5dblp 6.66 (1) 2.64 (2.52) 2.58 (2.58) 2.26 (2.95)Q6dblp 2.65 (1) 1.75 (1.51) 1.76 (1.50) 1.19 (2.23)

Table 4: Average runtimes of six queries over the DBLP dataset on the DiRT and Greenwolf platforms. On three of thequeries, speedup is significant (shown in boldface), thoughon the others there is very little speedup or even slowdown.Details about each query are given in Table 3.

the subsequent level the branch factor is much lower (rang-ing from B = 5 to B = 100). The chosen queries we usefor DBLP execute in a reasonable time on our multi-coreplatforms (between 1 and 100 seconds), have various nodeselection patterns, and thus lead to a range of performancebehaviors. See the top part of Table 3 for full details on eachquery.

As in Section 6, we measure the performance for all possi-ble p/c/h combinations for each query to determine the bestcombination. Figure 8 shows the parallel speedup achievedfor Q2dblp for each p/c/h combination on DiRT. The resultsindicate that, like previous synthetic experiments, the bestconfiguration for queries over the DBLP dataset as well isalso PCH-2/1/5. However, the maximum speedup achievedon queries over DBLP is 3.08, which is much less than pre-vious synthetic experiments. We see similarly poor parallelperformance for all queries we execute on the DBLP dataset.

The results of executing six diverse queries over DBLPare shown in Table 4 and indicate that PCH outperforms

Query Children % Children Completeof Root Match Query Query Matches

Q1dblp 2767177 0.60% 738Q2dblp 2767177 25.7% 1782468Q3dblp 2767177 <0.01% 50Q4dblp 2767177 0.32% 3319Q5dblp 2767177 36.2% 949501Q6dblp 2767177 36.4% 1008156

Table 5: Details about the DBLP dataset and queries. Theroot node has an enormous number of children (over 2.7million). The three queries that lead to poor parallel per-formance (Q1dblp, Q3dblp, and Q4dblp) have a very smallnumber of sub-match nodes. The high initial branch fac-tor and the low number of sub-matches contribute to loadimbalance.

SWP and WQ in all cases. However, we find that whilesome parallel speedup is achieved, it is much lower thanthat seen for synthetic experiments. Furthermore, it is in-consistent across queries. On both platforms, speedup be-tween 1.92 and 3.11 is achieved for queries Q2dblp, Q5dblp,and Q6dblp (results shown in boldface). However, queriesQ1dblp, Q3dblp, and Q4dblp show low parallel speedup (evena slowdown for Q4dblp). We obtain similar parallel speedupon Greenwolf (4 cores) and on DiRT (8 cores), showing thatparallel efficiency is low.

By examining the shape of the tree, we can determineif load imbalance is the cause of the poor parallel speedup.DBLP is a very large, shallow tree with widely varying num-bers of children per node. Table 5 outlines some detailsabout the dataset and our six queries. We see that the rootnode has a very large number of children, as expected. Forqueries Q1dblp, Q3dblp, and Q4dblp (those that show poorspeedup), a very small number of those children match thequery. We postulate that this, combined with the smallquery depth, causes load imbalance for all of our parallelquery engines. Figure 9 further illustrates the cause of loadimbalance.

The large initial branch factor and shallow query depthcombine to cause load imbalance that cannot be avoided byour query engines. Since all of the 2.7 million nodes at depth

Figure 9: An illustration of what a query over the DBLPmay look like and how work would be distributed amongthreads by a parallel query engine (nodes assigned to athread are grouped in boxes). In this example thread 1has a much larger workload than the other threads, thusdegrading parallel performance.

1 are children of the root node, they must all be processedby a single thread (the thread to which the root node is as-signed, say thread 1). While processing these nodes, thread1 writes query sub-matches to the shared workqueue. Otherthreads read these nodes from the workqueue and processtheir children. As Figure 9 shows, however, the small num-ber of matches and shallow total depth enables these nodesto be processed quickly, causing other threads to remainmostly idle while thread 1 works. This bottleneck at a sin-gle thread is also the reason for the comparable parallel per-formance between Greenwolf and DiRT (more cores do nothelp since they remain idle anyway). The three queries onwhich we do see significant parallel speedup (Q2dblp, Q5dblp,and Q6dblp) have a much higher selectivity, giving the otherthreads more work while thread 1 evaluates all 2.7 millionnodes.

As expected, idiosyncrasies of real-world datasets causeparallel performance degradation. However, despite the ex-treme shape of the DBLP dataset (2.7 million children ofthe root and a maximum depth of 3), PCH does achievesome parallel speedup on three of the queries, thereby out-performing SWP and WQ.

7.2 Experiments on XMarkThe XMark XML benchmark [19, 16] consists of an XML

file generator that creates sets of tags filled with large amountsof data. The size of the dataset created is controlled by asingle parameter, the scaling factor. To evaluate the per-formance of our XPath query engines on XMark we createa set of XML files ranging from 10MB to 1GB using theXMark dataset generator. We analyze these files to identifyseveral applicable queries that traverse different sections ofthe XML document tree. To get a broad profile of the per-formance of our XPath query engines on XMark datasets,we select queries with varying parameters, including depth.Details on these queries are shown in the bottom part ofTable 3.

Like all previous experiments, the best configuration isPCH-2/1/5, with a parallel speedup of 4.90 over sequentialexecution. Similar results are obtained for other XMarkqueries on both multi-core platforms.

Table 6 shows results for each parallel query engine oneach query on a scaling factor 10 XMark dataset (1.1GBin size). Even though parallel speedup is lower than thatobserved with synthetic datasets and queries, PCH achievesparallel speedup between 2.82 and 5.29 for all queries. These

Runtime in seconds and (speedup) on DiRTQuery Seq. SWP WQ PCHQ1xmark 2.08 (1) 0.74 (2.81) 0.71 (2.91) 0.42 (4.9)Q2xmark 0.93 (1) 0.92 (1.02) 0.77 (1.21) 0.33 (2.8)Q3xmark 1.19 (1) 0.56 (2.13) 0.52 (2.3) 0.37 (3.22)Q4xmark 1.01 (1) 0.64 (1.58) 0.65 (1.55) 0.19 (5.29)

Table 6: Average runtimes and speedup of four queries overthe XMark data set with scaling factor 10 on the DiRT plat-form. We see good parallel speedup on all queries with PCHand inconsistent results with SWP and WQ. Details abouteach query are given in Table 3.

results are for PCH-2/1/5, which was found to produce thebest results for all experiments performed thus far. SWPand WQ lead to inferior and inconsistent results, implyingthat for some queries load balance is poor with these queryengines.

8. CONCLUSIONThe prevalence of XML over the World-Wide Web and

other domains underscores the importance making XMLprocessing efficient. The proliferation of multi/many-coreplatforms provides new opportunities to improve XML pro-cessing performance, including XPath query evaluation. Whileseveral works have studied the concurrent execution of mul-tiple queries on these platforms, comparatively few authorshave investigated the parallelization of a single query [25,4, 3]. These works have had limited success in achievinghigh parallel performance. In this paper we have evaluatedthe performance of three different parallelization approachesthat achieve different trade-offs between overhead and loadimbalance. The first two approaches, SWP and WQ, cor-respond to well-known parallel computing techniques, whilethe third , PCH, is a generalization of the producer-consumerparadigm. We have evaluated implementations of paral-lel XPath query engines that use these three approacheson a range of synthetic and real-world datasets. Our re-sults indicate that the addition of Hybrid threads to thewell-known Producer-Consumer paradigm provides a signifi-cant improvement, though an all-Hybrid configuration is notideal. Through experimentation, we found that the PCH-2/1/5 configuration lead to best overall performance on our8-core environment (and PCH-1/0/3 using 4 cores). Us-ing this configuration, the PCH query engine consistentlyachieves good parallel speedup and out-performs our otherparallel query engines. However, PCH fails to achieve ac-ceptable parallel performance on some queries of the DBLPdataset. We have identified the cause of this behavior, whichis attributed to idiosyncratic features of certain queries onthat dataset. Overall, we expect PCH to lead to good resultsin the vast majority of practical scenarios.

A future direction for this work is to evaluate the per-formance of our three parallel XPath query engines on awider range of real-world datasets and using more cores todetermine how the performance of our query engines scales.Additional techniques besides parallelization can also be ap-plied to improve performance, such as indexing of node tags.Finally, a broader future direction would be to apply thePCH approach to other tree-traversal applications, such assearch trees.

9. REFERENCES[1] Automata for XML: A survey. Journal of Computer

and System Sciences, 73(3):289–315, 2007.

[2] A. Aboulnaga, A. Alameldeen, and J. Naughton.Estimating the selectivity of XML path expressions forinternet scale applications. In InternationalConference on Very Large Data Bases (VLDB), pages591–600, 2001.

[3] R. Bordawekar, L. Lim, A. Kementsietsidis, andB. Kok. Statistics-based parallelization of XPathqueries in shared memory systems. In InternationalConference on Extending Database Technology(EDBT), pages 159–170, 2010.

[4] R. Bordawekar, L. Lim, and O. Shmueli.Parallelization of path queries using multi-coreprocessors: Challenges and experiences. InInternational Conference on Extending DatabaseTechnology (EDBT), pages 180–191, 2009.

[5] Z. Chen, H. V. Jagadish, F. Korn, and N. Koudas.Counting twig matches in a tree. In InternationConference on Data Engineering (ICDE), pages595–604, 2001.

[6] G. Cong, W. Fan, A. Kementsietsidis, J. Li, andX. Liu. Partial evaluation for distributed XPath queryprocessing and beyond. In Transactions on DatabaseSystems, 2011.

[7] W. W. W. Consortium. XML path language (XPath)2.0. www.w3.org, 23 January 2007.

[8] Document Object Model (DOM) Technical Reports.http://www.w3.org/DOM/DOMTR.

[9] G. Gou and R. Chirkova. Efficiently querying largeXML data repositories: A survey. IEEE Transactionson Knowledge and Data Engineering,19(10):1381–1403, 2007.

[10] S. Haw and C. Lee. Data storage practices and queryprocessing in XML databases: A survey.Knowledge-Based Systems, 24:1317–1340, 2011.

[11] B. Karsin. Parallel XPath Query Evaluation onMulti-core Processors. Master’s thesis, University ofHawai‘i at Manoa, 2012.

[12] M. Ley. Digital bibliography and library project, 2011.

[13] L. Lim, M. Wang, S. Padmanabhan, J. Vitter, andR. Parr. XPathLearner: An on-line self-tuning markovhistogram for XML path selectivity estimation. InInternational Conference on Very Large Data Bases(VLDB), 2002.

[14] L. Lim, M. Wang, and J. S. Vitter. CXHist : Anon-line classification-based histogram for XML stringselectivity estimation. In International Conference onVery Large Data Bases (VLDB), pages 1187–1198,2005.

[15] W. Lu and D. Gannon. Parallel XML processing bywork stealing. In SOCP, pages 31–38, 2007.

[16] I. Mlynkova. XML benchmarking. In IADISInternational Conference on Applied Computing,pages 59–66, 2008.

[17] M. M. Moro, V. Braganholo, C. F. Dorneles,D. Duarte, R. Galante, and R. S. Mello. XML: Somepapers in a haystack. Special Interest Group onManagement Of Data (SIGMOD) Record, 38(2):29–34,2009.

[18] Simple API for XML. http://www.saxproject.org.

[19] A. Schmidt, F. Waas, M. Kersten, M. Carey,I. Manolescu, and R. Busse. XMark: A benchmark forXML data management. In International Conferenceon Very Large Data Bases (VLDB), pages 974–985,2002.

[20] J. Teubner, T. Grust, S. Maneth, and S. Sakr.Dependable cardinality forecasts for XQuery. VLDBEndow., 1(1):463–477, 2008.

[21] X. Wang, A. Zhou, J. He, W. Ng, and P. Hung.Multi-query evaluation over compressed XML data inDaaS. Lecture Notes in Business InformationProcessing, 74(3):185–208, 2011.

[22] Y. Wu, J. Patel, and H. Jagadish. Estimating answersizes for XML queries. In Internation Conference onExtending Database Technology (EDBT), pages590–608, 2002.

[23] Xalan. http://xml.apache.org.

[24] Y. Zhang, Y. Pan, and K. Chiu. A parallel xpathengine based on concurrent NFA execution. InInternational Conference on Parallel and DistributedSystems, pages 314–321, 2010.

[25] W. Zuo, Y. Chen, F. He, and K. Chen. Loadbalancing parallelizing XML query processing basedon shared cache chip multi-processor (CMP).Scientific Research and Essays, 6:3914–3926, 2011.