feat: A fully featured btree implementation #3126
Conversation
github-actions
bot
added
the
🧾 package/realm
|
Thanks! I need this for that https://github.com/TERITORI/teritori-dapp/blob/2a5c8390438e6aad332f71410bcf8aabaaecab4b/gno/p/havl/havl.gno#L18 |
wyhaines
changed the title
wyhaines
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
|
related with #3021 |
| @@ -0,0 +1 @@ | |||
| module gno.land/demo/p/btree | |||
There was a problem hiding this comment.
| module gno.land/demo/p/btree | |
| module gno.land/p/demo/btree |
| // Any type that implements this interface can be stored in the BTree. This allows considerable | ||
| // flexiblity in storage within the BTree. | ||
| type Record interface { | ||
| // Less compares self to `than`, returning true if self is less than `than` |
|
Would be really cool to see a mini tutorial in |
I will plan on writing one. Thanks for the suggestion. |
| // The btree package implements in-memory B-Trees of arbitrary degree. | ||
| // | ||
| // It has a flatter structure than an equivalent red-black or other binary tree, | ||
| // which may yield better memory usage and/or performance. | ||
|
|
||
| package btree |
There was a problem hiding this comment.
| // The btree package implements in-memory B-Trees of arbitrary degree. | |
| // | |
| // It has a flatter structure than an equivalent red-black or other binary tree, | |
| // which may yield better memory usage and/or performance. | |
| package btree | |
| // Package btree implements in-memory B-Trees of arbitrary degree. | |
| // | |
| // It has a flatter structure than an equivalent red-black or other binary tree, | |
| // which may yield better memory usage and/or performance. | |
| package btree |
There was a problem hiding this comment.
- mention that it is a fork of google/btree
| // BTree stores Record instances in an ordered structure, allowing easy insertion, | ||
| // removal, and iteration. | ||
| type BTree struct { | ||
| Degree int |
There was a problem hiding this comment.
Should this be modifiable by a user after creation?
| func New(params ...int) *BTree { | ||
| if len(params) == 0 { | ||
| return NewWithFreeNodeList(16, NewFreeNodeList(DefaultFreeNodeListSize)) | ||
| } else if len(params) == 1 { | ||
| return NewWithFreeNodeList(params[0], NewFreeNodeList(DefaultFreeNodeListSize)) | ||
| } else { | ||
| return NewWithFreeNodeList(params[0], NewFreeNodeList(params[1])) | ||
| } |
There was a problem hiding this comment.
This constructor is not explicit and is attempting to use variadic arguments for "overloading". This is generally bad practice in Go.
Can we simply make this work in the case for New(), just returning NewWithFreeNodeList(16, NewFreeNodeList(DefaultFreeNodeListSize))?
| // TODO: Is there any advantage to implementing this interface for all of the standard | ||
| // orderable types? |
There was a problem hiding this comment.
This can make sense as a subpackage, like p/demo/btree/cmp
This is a fully featured btree implementation. A friend gave me some incomplete (and broken) btree code for Go, and when I started reworking it, I discovered that it was a broken semi-copy of an old version of Google's btree for Go.
I finished reworking it so that it adhere's to that original Google version's API, though there are some differences internally in places, and I think that my version is much easier to follow and to understand.
This implementation is quite a bit faster than the AVL tree. I will add links to some benchmarks that I did in a comment. This implementation supports copy-on-write for the trees, for inexpensively creating copies of a tree that are effectively isolated from each other with respect to changes that happen after the fork.
Contributors' checklist...
BREAKING CHANGE: xxxmessage was included in the description