| Table of Contents |
|---|
...
| Existing solution | Proposed 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. |
|
|
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)
...
| Case | Query one out of many using descendant cps path | Query one out of many using absolute cps path |
|---|---|---|
| Query | //openroadm-device[@device-id="C201-7-1A-14"] | /openroadm-devices/openroadm-device[@device-id="C201-7-1A-19"] |
| Comparison graph |
|
|
| Graph detail |
|
|
Time complexity of | O(N) | O(N) |
| Time complexity of proposed solution | O(N) | O(1) |
...