Remove history btree #1861
Remove history btree #1861
Conversation
| @@ -43,11 +45,11 @@ type change[T any] struct { | |||
|
|
|||
| // Wrapper around a changeSummary that allows comparison | |||
| // of when the change was made. | |||
| type changeSummaryAndIndex struct { | |||
| type changeSummaryAndInsertNumber struct { | |||
There was a problem hiding this comment.
Kind of verbally clunky but I think InsertNumber is better than index since this isn't actually an index into anything, and I don't want people to think it's an index into history. I'm open to other names
| // [lastEndRootChange] is the last change in the history resulting in [endRoot]. | ||
| lastEndRootChange, ok := th.lastChanges[endRoot] | ||
| // [endRootChanges] is the last change in the history resulting in [endRoot]. | ||
| endRootChanges, ok := th.lastChanges[endRoot] |
There was a problem hiding this comment.
Changed to endRootChanges for parallel naming with startRootChanges
…o into remove-history-btree
| // There's no change resulting in [startRoot] before the latest change resulting in [endRoot]. | ||
| if startRootChanges.index > lastEndRootChange.index { | ||
| return nil, ErrStartRootNotFound | ||
| var ( |
There was a problem hiding this comment.
should these be calculated after figuring out the insert number of the start root before the endroot?
There was a problem hiding this comment.
the end root index has to be calculated here but I moved the start root index calculation below after we know startRootChanges is correct
There was a problem hiding this comment.
I mean technically we could move this:
var (
// The insert number of the last element in [th.history].
mostRecentChangeInsertNumber = th.nextInsertNumber - 1
// The index within [th.history] of its last element.
mostRecentChangeIndex = th.history.Len() - 1
// The difference between the last index in [th.history] and the index of [endRootChanges].
endToMostRecentOffset = int(mostRecentChangeInsertNumber - endRootChanges.insertNumber)
// The index in [th.history] of the latest change resulting in [endRoot].
endRootIndex = mostRecentChangeIndex - endToMostRecentOffset
)into the
if startRootChanges.insertNumber > endRootChanges.insertNumber {clause and then recalculate the endRootIndex by using the startRootIndex later but I think it's cleaner as is
Why this should be merged
Using a
buffer.Dequeis faster than using a btreeHow this works
Use deque instead of btree to hold changes sorted by increasing change number
How this was tested
Existing/updated UT