Graph View. Usage Tiers
Three graph sizes representing shallow, mid-depth, and deep project graphs. Each measures data generation, JSON round-trip, BFS traversal, and edge-update throughput.
The BFS traversal runs when the graph is rebuilt. The graph rebuilds whenever the current context or graph settings change.
Tier 1. Shallow (cap=50, depth=2)
| Operation | Time | Notes |
|---|---|---|
| Data generation | 1.3 ms | |
| JSON serialise | 11.1 ms | 186 KB output |
| JSON deserialise | 4.5 ms | |
| BFS traversal | 0.7 ms | 2,551 nodes visited |
| UpdateGraphEdge | 62.5 ms | 10,000 transitions · pool=50 · cap=50 |
Tier 2. Mid (cap=20, depth=3)
| Operation | Time | Notes |
|---|---|---|
| Data generation | 2.6 ms | |
| JSON serialise | 8.6 ms | 623 KB output |
| JSON deserialise | 13.6 ms | |
| BFS traversal | 1.2 ms | 8,421 nodes visited |
| UpdateGraphEdge | 40.2 ms | 10,000 transitions · pool=50 · cap=20 |
Tier 3. Deep (cap=20, depth=4)
| Operation | Time | Notes |
|---|---|---|
| Data generation | 43.7 ms | |
| JSON serialise | 171.1 ms | 12,475 KB output |
| JSON deserialise | 283.0 ms | |
| BFS traversal | 27.1 ms | 168,421 nodes visited |
| UpdateGraphEdge | 39.0 ms | 10,000 transitions · pool=50 · cap=20 |
Assertion: UpdateGraphEdge time does not meaningfully scale with graph depth. It remains in the 39–63 ms range across all three tiers. The cost is dominated by pool and cap size, not total node count.
Stress Test. Not Realistic
An extreme scenario far beyond any real project. Included for reference only to understand theoretical ceiling behaviour.
| Operation | Time | Notes |
|---|---|---|
| Data generation | 2,967.8 ms | |
| JSON serialise | 10,362.1 ms | 465,486 KB (~454 MB) |
| JSON deserialise | 16,191.6 ms | |
| BFS traversal | 2,054.5 ms | 6,377,551 nodes visited |
| UpdateGraphEdge | 119.9 ms | 10,000 transitions · pool=50 · cap=50 |
Assertion: Even at 6.4 million nodes, UpdateGraphEdge completes in under 120 ms. This further supports that edge update cost scales with pool/cap configuration, not graph size. The real bottleneck at this scale is serialisation. Serialisation only occurs on save and load, which are infrequent operations. Not a concern in practice.
Graph View. Physics Limits
Real-time physics simulation at the maximum supported node count of 500 nodes / 499 edges.
| Operation | Time | Notes |
|---|---|---|
| PopulateGraph (BFS + spawn) | 184.5 ms | One-time cost on open |
| Physics tick (single) | 12.4 ms | First few frames. Worst case. |
| Physics tick (avg over 100) | 7.71 ms | ~130 fps physics-only throughput |
Node repulsion is O(N²). The first few frames carry maximum repulsion force between all node pairs before the simulation settles. This test measures that worst-case. Steady-state frame cost will be lower. Halving the node count cuts physics cost by approximately 4×.
List View. Maximum Capacity
The List tab at cap=50, measuring how quickly context assets can be retrieved on selection change.
| Operation | Time | Notes |
|---|---|---|
| GetContextAssets. Cold | 15.36 ms | AssetDatabase lookup, paid once per selection change |
| GetContextAssets. Warm | 0.33 ms | Result cache hit; subsequent repaints use this path |
Assertion: The 46× difference between cold and warm cost means repaints are essentially free. Only a selection change pays the full lookup price.
Recent Tab. Maximum Capacity
The Recent tab at maximum history depth, measuring the cost of rebuilding the display list from persisted history.
| Operation | Time | Notes |
|---|---|---|
| History rebuild | 12.62 ms | AssetDatabase lookup per entry; paid once per history change |
| Per-entry average | 0.126 ms | Across 94 resolved entries |
Like the List view, this cost is paid only when history changes. Subsequent repaints use a cached display-entry list and incur no additional lookup cost.
Summary
All measurements are from a single test run on 2026-08-31. The tiers below reflect realistic usage; the stress test is included as a theoretical reference only.
- Graph generation and traversal scale predictably with node count and remain well under 50 ms for any realistic project graph (Tier 1–2).
- Edge updates are bounded by pool and cap configuration, not graph size. Consistent across 2,500 to 6.4 million nodes.
- Physics simulation at 500 nodes runs at ~130 fps worst-case (first frames only); steady-state will be faster.
- List and Recent tab lookups are O(1) after the first selection. Cache hits cost under 0.5 ms.
- JSON serialisation is the only operation that scales steeply with node count. It only occurs on save and load, which are infrequent operations.