chore(lib/trie): refactor encoding and hash related code in trie package#2077
chore(lib/trie): refactor encoding and hash related code in trie package#2077qdm12 merged 50 commits intodevelopmentfrom
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
| // 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.
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.
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.
|
|
||
| // 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.
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.
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
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
noot
left a comment
There was a problem hiding this comment.
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.
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. |
noot
left a comment
There was a problem hiding this comment.
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/recordersub-package #2082Type() Typemethod #2086Tests
Issues
Primary Reviewer