anilpacaci / rpq Goto Github PK

Assess the impact of DropWizard on performance. Measure its impact on system tput and total memory overhead

Epsilon transitions can simply be supported.
In each insert to delta, simply check if there is an epsilon transition, if so progress the automata

Adapter to parse gMark output and run experiments similar to STQueryRunner

Query runner should read the output directory of gMark, open the gMark stream from given folder, then execute all the queris given in SPARQL format

Make sure that gMarkTextStream adds p to each predicate as queries are formulated that way.

In addition, size of the query, total number of alternation/conjuncts/kleene star and the number of automata states should be reported

For RSPQ, each node maintains two separate hashets for first markings and current markings. This information can be captured in compact, vector based representation

We can partition Delta based on spanning trees, each worker would be responsible of subset of trees. This would provide a straightforward way to partition data.

Then we can use DAGreedy based approach to balance thread workloads as necessary

Main automata transition logic is implemented in recursive processEdge function. Get rid of recursion and measure its performance impact

Programmatic QueryAutomata generation. Can use Jena ARQ parser to parse SPARQL property paths, then construct the automaton

Current implementation of batching assigns group of spanning trees to a thread, then execute in batches (WindowedRPQ.java).
This batching logic can be captured in SpanningTreeExpansionJob

This issue is related to #15 . We can maintain a buffer for incoming edges in each partition, then we can potentially parallelize execution of multiple stream tuples. Here each buffer needs to maintain FIFO order to ensure correctness within a spanning tree.