-
Notifications
You must be signed in to change notification settings - Fork 124
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
chore(lib/trie): refactor encoding and hash related code in trie package #2077
Conversation
Codecov Report
@@ Coverage Diff @@
## development #2077 +/- ##
===============================================
+ Coverage 61.35% 61.55% +0.19%
===============================================
Files 202 213 +11
Lines 27355 27390 +35
===============================================
+ Hits 16785 16860 +75
+ Misses 8694 8665 -29
+ Partials 1876 1865 -11
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
7069bd3
to
91ed716
Compare
lib/trie/branch/encode.go
Outdated
// ScaleEncodeHash hashes the node (blake2b sum on encoded value) | ||
// and then SCALE encodes it. This is used to encode children | ||
// nodes of branches. | ||
func (b *Branch) ScaleEncodeHash() (encoding []byte, err error) { |
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.
nit: I would assume Encode functions take an io.Writer
.
func (b *Branch) ScaleEncodeHash() (encoding []byte, err error) { | |
func (b *Branch) ScaleMarshalHash() (encoding []byte, err error) { |
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.
Actually if I do that that will be an extra copy (buffer's Write()
implementation is a copy), since there is no scale encoder writing to a io.Writer directly. Maybe do you feel like adding such encoder in the scale package? That would allow to use a writer directly now. Or let me know I can do eventually do it quickly tomorrow sometime.
As in I guess I'm pre-optimizing this although we have another elephant size memory problem, but this part of the code seems to be quite cpu and memory intense still so it shouldn't hurt to save a copy.
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.
I created an issue a while ago for this. #1897
lib/trie/decode/key.go
Outdated
|
||
// KeyLEToNibbles converts a Little Endian byte slice into nibbles. | ||
// It assumes bytes are already in Little Endian and does not rearrange nibbles. | ||
func KeyLEToNibbles(in []byte) (nibbles []byte) { |
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.
I feel like there should be some sort of Key
type, and this function should just be a receiver function on that type.
Key.Nibbles() ([]byte)
.
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.
I started working on it in a branch, but it's a lot more changes than I expected. I will pause it for now but taking note to do it at a later time eventually.
b59fd4b
to
0a7aafa
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.
I don't really like the idea of separating node (branch and leaf) types into separate packages, imo they should stay unexported as they don't need to show up in the API docs. node
should be used only internally to the trie package imo
I can move them in the internal directory such as internal/trie/node so they won't show in docs/as API outside this project. I think we also all agree both branch and leaf packages should be moved together in the node subpackage as well. However we do need subpackages, the trie package is way too dense, so we can't go back to have everything in a single package and have unexported things. |
c1f22e9
to
30e2318
Compare
Let me know if that fits what you wanted π Thanks! |
f46613f
to
be205de
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.
tbh I don't know how I feel about moving everything into separate packages, I feel like it's more confusing but if you think it's clearer then happy to review :p
It does make sense to me to split it since node/leaf/branch can be split apart from the trie / database / generations / pruning operations. I'm opposed to have many nested micro packages, but here we really had some heavy weight trie package πΈ I'm working now off this branch and it feels quite nicer I think. |
be205de
to
6f38613
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.
This is tricky since I don't have a clear view on what has changed and what has moved. I have tried to comment wherever I see problems, but I have also ran quickly with some parts and avoided some comments since I don't think it is a good idea to add more changes in this PR.
- I don't like that some smaller parts have their own files, for example dirty, key, generation, value, copy, etc.
- To me, methods of same struct being together(in the same file) makes more sense than same methods of similar structs.
- It might be possible to just merge Leaf and Branch struct. It might require some gymnastic like using an interface for methods that are different or functions as values. But if we can do that, that could make some things clearer. (Not as part of this PR)
Though I have made some smaller comments, we should (I realize that now) not make more changes in this PR to keep things simpler.
Agreed. There was unfortunately no way to split the changes really due to the file movements.
So I am confident no bug was introduced. But I agree it's hard to review.
Feel free to comment, I already have a few PRs pointing to this PR, adding a few more is fine too. I'll rebase them on development once this one merges.
Agreed; however the alternative is to have only a
Definitely. I'll explore this once the memory issue is fixed. Added this to my list of suggestions. |
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.
looks good, just minor comments!
de4b2a8
to
61baed1
Compare
πββοΈ don't be too scared by the deltas, it is mostly test and mock code being moved in subpackages
Changes
Notes
Branched out PRs
lib/trie/recorder
sub-packageΒ #2082Type() Type
methodΒ #2086Tests
Issues
Primary Reviewer