Reachability store should be refactored in the same way to alleviate the current bottleneck of storing reachability data in a one struct.
Context: performance of IDB is impacted when the DAG becomes wider and RelationsStoreExtensions::insert_batch can take a lot of time. This is due to the block children being stored under one key making the operation to add child blocks O(N^2).
Extra Caveat: in reachability store the children are sorted by their reachability interval to make binary search possible later. If each child is saved separately they won't be sorted. Solution: save the children unsroted, and sort them only when they are cached
coderofstuff
commented
9 months ago
Follow-up to https://github.com/kaspanet/rusty-kaspa/pull/325
Reachability store should be refactored in the same way to alleviate the current bottleneck of storing reachability data in a one struct.
Context: performance of IDB is impacted when the DAG becomes wider and
RelationsStoreExtensions::insert_batchcan take a lot of time. This is due to the block children being stored under one key making the operation to add child blocks O(N^2).Extra Caveat: in reachability store the children are sorted by their reachability interval to make binary search possible later. If each child is saved separately they won't be sorted. Solution: save the children unsroted, and sort them only when they are cached