feat: more compact exported snapshot#703
Conversation
be44270 to
7c9c9d0
Compare
tac0turtle
left a comment
There was a problem hiding this comment.
lets leave this here for now, in store v2 this could be moved higher, into the sdk
| n.Key = nil | ||
|
|
||
| // delta encode the version | ||
| maxVersion := maxInt64(e.versionStack[len(e.versionStack)-1], e.versionStack[len(e.versionStack)-2]) |
There was a problem hiding this comment.
just curious about the efficiency of version delta encode?
Just did some more detailed comparisons, in the "without zlib compression" table, version delta only contributes 2% more compression rate, but those contributions are carried over to the with-zlib scenario, where it has more significant impact, I guess it's a part that is not handled well by zlib compression: With Zlib Compression(level 7)
Without Zlib Compression
Zlib Level 3I did another round with zlib level 3 compression, it seems provide better trade-off in general, lose some marginal compression rate but being much faster.
|
|
txs for detail report |
|
@Mergifyio backport release/v1.x.x |
✅ Backports have been createdDetails
|
Co-authored-by: cool-developer <51834436+cool-develope@users.noreply.github.com> Co-authored-by: Marko <marbar3778@yahoo.com> (cherry picked from commit b544dc0) # Conflicts: # CHANGELOG.md
Closes: #690 #688
ExportNodetype as the exchange format with sdk, sdk can still use the protobuf encoding as before, which skips empty fields, which works well with the new optimizations.Where to put the code
With the approach taken in this PR, it's totally fine to move the logic to the sdk side as well, if it makes more sense.
Test Result
Dumped from cronos mainnet data, evm module, version 2000000:
14%, not as big as expected, I guess mainly because zlib compression already done a good job.EDIT:
Just to confirm my suspicion, I recreate the snapshot with zlib compression disabled, it goes like this:
The compression rate is
54%.