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
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
The text was updated successfully, but these errors were encountered:
Follow-up to #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_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
The text was updated successfully, but these errors were encountered: