-
Notifications
You must be signed in to change notification settings - Fork 89
Conversation
I went through the scrolls we've inherited to track down the change 😄 Seems like it was added in 1546716#diff-168726dbe96b3ce427e7fedce31bb0bcR597 and modified again in 236b43a#diff-168726dbe96b3ce427e7fedce31bb0bcR535. Couldn't find any explanation so far. Btw if this is not only a performance optim, I expect the change in behaviour to happen in VM tests when you drop the And removing it every time (in baseTrie) could itself have a performance penalty. Right now by not deleting nodes from db we're trading memory for speed. |
@s1na ah thanks, you are right, I didn't consider that ignoring deletion of the nodes could actually primarily be for the performance boost. I will modify this PR to better document some of this instead of modifying any behavior. |
99d2d6b
to
ae4a3b9
Compare
_formatNode
_formatNode
42de1d0
to
53f4466
Compare
src/checkpointTrie.ts
Outdated
_formatNode(node: TrieNode, topLevel: boolean, opStack: BatchDBOp[], remove: boolean = false) { | ||
console.log('ENTERING HERE') |
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.
Here is a console.log left. Is this otherwise ready for review?
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.
thanks got it. yes ready for review, i'll publish, just ended up being some typedoc additions and typo fixes.
* Fix typos e.g. extention => extension
53f4466
to
71c3aac
Compare
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.
LGTM
This PR:
_formatNode
and_walkTrie
extention
=>extension
While refactoring I found that
_formatNode
has a parameterremove
that is not being utilized inside the method inbaseTrie.ts
but is being used incheckpointTrie.ts
. It is called with the value beingtrue
in two cases: here and here.In its history, the
remove
parameter was used alongsideif (this.isCheckpoint)
on whether to remove the node by pushing adel
op to the opStack.Asking @s1na, he mused:
So, is the
remove
parameter checked withisCheckpoint()
just an optimization for copying less data to the db in acommit()
? Are there any other uses or cases? There doesn't seem to be any test cases covering these scenarios.