You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are use cases that need to analyze the CST without tracking offsets. This means they shouldn't pay the cost of maintaining these numbers as the cursor is running. One idea is to provide another node.create_*() API that creates a fast Cursor that can implement all same API, but won't track or provide offset values.
However, this is a nice-to-have feature, and we can put it aside for later if it will result in two divergent implementations.
@AntonyBlakey@OmarTawfik I know we were on the fence with this one; do we still plan to implement this? I feel that this is more in the P3 area as it's exploratory and not tracking the offsets doesn't sound like that big of a win, considering the fact that we traverse the tree by jumping to different allocations when walking the tree and so incrementing the counters well within the cache probably doesn't cost us much relative to that.
@Xanewok it is definetely a P2 (previously known as P3), but in any case, I think it is worth a quick test (once we have a perf harness) to validate these assumptions.
fast cursors (no offsets)
There are use cases that need to analyze the CST without tracking offsets. This means they shouldn't pay the cost of maintaining these numbers as the cursor is running. One idea is to provide another
node.create_*()
API that creates a fast Cursor that can implement all same API, but won't track or provide offset values.However, this is a nice-to-have feature, and we can put it aside for later if it will result in two divergent implementations.
Separated from #628
The text was updated successfully, but these errors were encountered: