-
Notifications
You must be signed in to change notification settings - Fork 27
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: move initialization of StableBTreeMap
cursors into Iter
#231
base: main
Are you sure you want to change the base?
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add a short description of what the changes are trying to accomplish.
I also notice a non-negligible performance regression for insert
operations. Do you have an idea why that might be?
I'm surprised by the performance regression around inserts since I should have only affected reading and iterating over the map. I'll have a look into it tomorrow though. |
|
Actually, I think we might be seeing a race condition here because around the same time, Islam bumped the canbench version used. By visually comparing the numbers, I think you get pretty much the same after that PR. Yeah, the bot edited the results at some point but not the summary of the comment (still says significant change detected but all results are now within noise, this is a separate issue that we should fix I guess). |
I've been doing the work to move all chat events in OpenChat to stable memory, but this required
StableBTreeMap
to implementDoubleEndedIterator
since we need to be able to iterate chat events in either direction.I have implemented this on my own fork (here).
Rather than submit a fairly large PR containing the entire change, I have broken it into 2 deliverable pieces, with this PR being the first one.
Before this PR, the
StableBTreeMap
cursors would be initialised before iteration starts, which is fine if you'll always be iterating forwards.But once you can iterate in either direction, it is beneficial to only calculate the cursors for your direction of iteration when required, because if you only iterate in one direction, the cursors for the other direction are never needed.
So all this PR does is delay the initialization of the cursors until the first call to
Iterator::next
.