MemIAVL Benchmark

We use cronos mainnet data for the benchmark.

Snapshot Restoration

Prepare a snapshot of 8190000 (you can try a different version, should not affect the general result) in local snapshot store, and run following command with and without memiavl:

time --verbose cronosd snapshots restore 8190000 2 --home <node path>

	Wall Time	Peak RSS	DB Size
IAVL(goleveldb)	15h59m17	9.36G	22G
MemIAVL	5m8s	82.57M	14G

Block Replaying

Prepare Block Store

To remove the effect of networking latency during the benchmark, we prepare the block store first.

Backup the app state db restored above first (application.db and memiavl.db), which are useful later.

Setup state-sync and bootstrap the cometbft state:

cronosd tendermint bootstrap-state --home <node path>

Then start up the node normally until target height (you can enable memiavl for faster sync):

cronosd start --home <node path> --halt-height 8200000

Then we restore the backup app state, now the cometbft db has 10k more blocks than app state, and when node startup the abci handshake will replay those blocks locally.

Local Sync

Run following command with and without memiavl:

time --verbose cronosd start --home <node path> --halt-height 8200000

	Wall Time	Peak RSS
IAVL(goleveldb)	33m34s	3.45G
MemIAVL	2m40s	9.73G[^1]

Snapshot Export

Run following command with and without memiavl:

time --verbose cronosd snapshots export --height 8200000 --home <node path>

	Wall Time	Peak RSS
IAVL(goleveldb)	10h25m[^2]	2.48G
MemIAVL	8m14s	16.8G

[^1]: RSS comparison is actually unfair to memiavl, because the OS page caches backing the mmap-ed file are counted into user process's RSS, while those backing the file read/write operations are not, the leveldb/rocksdb also heavily rely on the OS page caches, but those caches are not counted in the recorded RSS numbers.

[^2]: the goleveldb task failed at around 90% progress, because of goleveldb dependency bug, may need to re-run the benchmark with different version or different backends.