add filter functionality - #16
Conversation
| const MAX_SIZE: usize, | ||
| > Drop for RedBlackTreeDrainFilter<'a, K, V, P, MAX_SIZE> | ||
| { | ||
| fn drop(&mut self) { |
There was a problem hiding this comment.
The gist of the speed up here is that the traversal traversal to remove nodes is O(K) instead of O(K log N) right?
There was a problem hiding this comment.
Actually still O(K log N) but you save a log N on the find
There was a problem hiding this comment.
Essentially, with remove you have to traverse the tree from the root to the entry to re-find the node addr of the entry you just found.
If you iterate through the elements and record the addr instead of the keys, you don't have to do that traversal to remove the entry. That's the gist
| .nodes | ||
| .get((ptr - 1) as usize) | ||
| .unwrap() | ||
| .get_value(); |
There was a problem hiding this comment.
is there not a helper function to perform this lookup?
There was a problem hiding this comment.
This part was mostly copied from the iterator implementation, but perhaps
There was a problem hiding this comment.
switched to get_node. much neater
jarry-xiao
left a comment
There was a problem hiding this comment.
Clever change! Please bump the version in the Cargo.toml
Will do. Also, it's come to my attention that the I'll try to come up with some better names for the methods. |
|
|
One final thing we may want to do is either implement |
This provides a
drain_filterandfilterfunctionality on the red black tree implementation.Inspiration: in
phoenix-v1'sCancelAllOrdersinstruction, the tree is traversed and matching ids are collected. These ids are then used viabook.remove(...)which traverses the tree to remove the entry. Instead of traversing the tree, this implementation records allocator node addresses and removes them all upon dropping the newRedBlackTreeDrainFiltertype.A quick and dirty benchmark of 128 removals from a full tree of 4096 items yields the following results on an M2 Max:
which is an O(30%) reduction in the wall time of the removals.