Trace GPS resolver during map queries
This commit is contained in:
@@ -81,10 +81,14 @@ Active build note:
|
||||
This is meant to identify whether class/mask filtering, rather than the edge
|
||||
multiplier table, is dominating route choice.
|
||||
- The resolver probe logs selected packed-handle resolutions from the
|
||||
search/materialization corridor. It decodes point index, segment index, and
|
||||
generation bits, then dumps the resolved 0x68-byte segment record and
|
||||
0x14-byte point record. The purpose is to see whether the edge-cost stage can
|
||||
reach final lane hashes/resource-side road classes before a path is chosen.
|
||||
search/materialization corridor. The selected post-call return sites are
|
||||
`0x44cb9e` (0x38 intermediate-record builder) and `0x44dd97`
|
||||
(geometry/materialization path). For full-map GPS queries from caller
|
||||
`0x8d20d4` with `query_fcc=5`, it opens a five-second resolver trace window,
|
||||
decodes point index/segment index/generation bits, then dumps the resolved
|
||||
segment/point records plus small raw slices behind segment pointer fields.
|
||||
The purpose is to see whether route materialization can reach final lane
|
||||
hashes/resource-side road classes before the final 0x28 records are emitted.
|
||||
|
||||
Current route-probe focus:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user