graph-bench now runs the six SNB Interactive complex reads against zu, tamnd/graph-bench#85. All six verify, and the picture splits cleanly by shape.
At sf1, fast profile, zu in process over libzu against ladybug in process on the same machine:
snb-ic1 zu p50 786.68ms p99 1129.27ms, ladybug p50 262.10ms p99 459.88ms, 0.3x
snb-ic2 zu p50 0.89ms p99 3.88ms, ladybug p50 6.43ms p99 8.93ms, 7.2x
snb-ic4 zu p50 11.64ms p99 71.05ms, ladybug p50 11.26ms p99 24.55ms, 1.0x
snb-ic5 zu p50 0.09ms p99 0.29ms, ladybug p50 2.85ms p99 10.58ms, 33.3x
snb-ic9 zu p50 9.58ms p99 52.37ms, ladybug p50 7.59ms p99 15.68ms, 0.8x
snb-ic13 zu p50 0.04ms p99 0.25ms, ladybug p50 1.52ms p99 3.07ms, 41.8x
Where the work is a one hop neighbourhood or a shortest path, zu is 7x to 42x ahead. Where the work is a bounded variable-length expansion it is behind. IC1 walks KNOWS one to three hops and then filters on firstName, and it is the only shape that loses by a wide margin. IC9 walks one to two hops and loses narrowly. IC13 walks KNOWS unbounded and wins by 42x, which is the tell: the shortest path selector stops at the first meeting and the bounded range does not.
The text is not the problem. IC1 in zuQL is the Cypher text unchanged, so the difference is what the plan does with a bounded range.
What to look at, in the order I would look at it.
A bounded range enumerates paths where the query only wants the reachable set. IC1 returns DISTINCT persons, so every path to a person past the first is work thrown away. RecursiveBFS already claims a node in the round it is first reached, so the level frontier is the right answer and the enumeration on top of it is the waste.
The filter is not pushed into the expansion. firstName is a selective property and the plan reads it after the third hop rather than using it to prune the frontier.
The 25ms subgraph in-process budget in graph-bench is missed by both engines on IC1, so that gate does not distinguish them today. Once the expansion is fixed it should, and the budget is worth revisiting then.
Reproduce with graph-bench at sf1: run --workload snb-complex --engines zu,ladybug --scale sf1 --profile fast.
graph-bench now runs the six SNB Interactive complex reads against zu, tamnd/graph-bench#85. All six verify, and the picture splits cleanly by shape.
At sf1, fast profile, zu in process over libzu against ladybug in process on the same machine:
snb-ic1 zu p50 786.68ms p99 1129.27ms, ladybug p50 262.10ms p99 459.88ms, 0.3x
snb-ic2 zu p50 0.89ms p99 3.88ms, ladybug p50 6.43ms p99 8.93ms, 7.2x
snb-ic4 zu p50 11.64ms p99 71.05ms, ladybug p50 11.26ms p99 24.55ms, 1.0x
snb-ic5 zu p50 0.09ms p99 0.29ms, ladybug p50 2.85ms p99 10.58ms, 33.3x
snb-ic9 zu p50 9.58ms p99 52.37ms, ladybug p50 7.59ms p99 15.68ms, 0.8x
snb-ic13 zu p50 0.04ms p99 0.25ms, ladybug p50 1.52ms p99 3.07ms, 41.8x
Where the work is a one hop neighbourhood or a shortest path, zu is 7x to 42x ahead. Where the work is a bounded variable-length expansion it is behind. IC1 walks KNOWS one to three hops and then filters on firstName, and it is the only shape that loses by a wide margin. IC9 walks one to two hops and loses narrowly. IC13 walks KNOWS unbounded and wins by 42x, which is the tell: the shortest path selector stops at the first meeting and the bounded range does not.
The text is not the problem. IC1 in zuQL is the Cypher text unchanged, so the difference is what the plan does with a bounded range.
What to look at, in the order I would look at it.
A bounded range enumerates paths where the query only wants the reachable set. IC1 returns DISTINCT persons, so every path to a person past the first is work thrown away. RecursiveBFS already claims a node in the round it is first reached, so the level frontier is the right answer and the enumeration on top of it is the waste.
The filter is not pushed into the expansion. firstName is a selective property and the plan reads it after the third hop rather than using it to prune the frontier.
The 25ms subgraph in-process budget in graph-bench is missed by both engines on IC1, so that gate does not distinguish them today. Once the expansion is fixed it should, and the budget is worth revisiting then.
Reproduce with graph-bench at sf1: run --workload snb-complex --engines zu,ladybug --scale sf1 --profile fast.