Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Existing solutionProposed solution

Because the existing solution uses a regex, all nodes in anchor 3 need to be examined to see if they match the regex.

Because the proposed solution uses sub-queries to look up each path component, only relevant nodes are examined.

  • Green and yellow nodes have been checked against the regex.
  • Yellow nodes matched the regex, and thus have JSON attributes examined.

  • Green nodes have been looked up using an index-only lookup.
  • Yellow nodes have had JSON attributes examined.

If the number of nodes is doubled, the number of xpaths checked against the regex is also doubled (linear complexity).

If the number of nodes is doubled, the same number of nodes is still scanned in this case (constant complexity).

Detailed Performance Comparison

Proof of Concept

A proof of concept (poc) implementation was developed so that performance could be compared against existing Cps Path query algorithms.

Test

...

setup

These tests below were performed using Groovy/Spock tests, directly calling the CPS-Service Java API (thus these tests do not include any HTTP overhead as when REST APIs are used).

...

The test timings used to generate the charts in this document is available as a spreadsheet: CPS-1646 CpsPath queries using path-component lookup.xlsx

...

Query one device out of many (1 out of N)

...