You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See #2100 and #1848 for work done up to this point and resources on snap sync.
Starting with a new master tracker ticket for continuing work on snap sync. We currently have the ability to perform a static sync. Next step is to support a moving sync.
You should benchmark the differences in this instantation of the trie using leveldb versus just removing that leveldb from the trie constructor (which would then default to using the MapDB from our util library. My suspicion is that the map DB is slightly faster.
Okay, so here's some benchmarking for mapdb vs leveldb. Here's my benchmarking script:
import{Trie}from'@ethereumjs/trie'import{randomBytes}from'crypto'//@ts-ignoreimport*asbenchfrom'micro-bmark'import{LevelDB}from'./level'const{ mark, compare, run }=bench// Or, use as suchconsttrieOps=async(trie: Trie)=>{constx=newUint8Array(300)forawait(const_lofx){awaittrie.put(randomBytes(32),randomBytes(32))}}run(async()=>{awaitmark('mapdb',100,async()=>trieOps(newTrie()))awaitmark('level',100,async()=>trieOps(newTrie({db: newLevelDB()})))})
I'm using micro-bmark as my benchmark tool here so you'll have to install that. But, the results seem reasonably convincing to me for switching from the leveldb to mapdb:
See #2100 and #1848 for work done up to this point and resources on snap sync.
Starting with a new master tracker ticket for continuing work on snap sync. We currently have the ability to perform a static sync. Next step is to support a moving sync.
cc: @g11tech @jochem-brouwer @holgerd77
The text was updated successfully, but these errors were encountered: