-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: A fully featured btree implementation #3126
Conversation
Thanks! I need this for that https://github.com/TERITORI/teritori-dapp/blob/2a5c8390438e6aad332f71410bcf8aabaaecab4b/gno/p/havl/havl.gno#L18 |
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
related with #3021 |
Would be really cool to see a mini tutorial in |
I will plan on writing one. Thanks for the suggestion. |
I'm a bot that assists the Gno Core team in maintaining this repository. My role is to ensure that contributors understand and follow our guidelines, helping to streamline the development process. The following requirements must be fulfilled before a pull request can be merged. These requirements are defined in this configuration file. Automated Checks🟢 Maintainers must be able to edit this pull request Manual Checks
Debug
|
Co-authored-by: Morgan <[email protected]>
Co-authored-by: Morgan <[email protected]>
…nted a Go functional pattern for configuring the btree.
In order to persist the link in the issue, for posterity, here are some timings that I did with the AVL tree, an AVL tree with one (of two that I have done) COW implementation, and the btree. https://docs.google.com/spreadsheets/d/1_Q6Mas-IYs4REu6MZrDTcywAGn8EVAbNOX9CDw01WGk/edit?usp=sharing I ran each test 9 times, and captured both the startup time for each test, and the total run time, so that the effective run time for each iteration can be determined. I also captures max RSS. So, for instance, if the startup time is 0.81 seconds, and the run time is 35.83 seconds, then the time spent actually performing the benchmark actions was 35.02. The tl;dr is that the btree is a lot faster than the AVL tree, at the cost of slightly more memory usage, unless trees are copied, in which case the memory usage from the btree is substantially less than the AVL tree. |
@wyhaines this CI check was red when you merged this PR, that's why the CI is red on master right now. The error is:
|
Why was this PR merged? |
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. <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests </details>
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. <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests </details>
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. <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests </details>
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: xxx
message was included in the description