Conversation
62904a0 to
5bdb7b4
Compare
0a1cc10 to
e750b5d
Compare
All encoding/decoding operations read the type cache to find the writer/decoder function responsible for a type. When analyzing CPU profiles of geth during sync, I found that the use of sync.RWMutex in cache lookups appears in the profiles. It seems we are running into CPU cache contention problems when package rlp is heavily used on all CPU cores during sync. This change makes it use atomic.Value + a writer lock instead of sync.RWMutex. In the common case where the typeinfo entry is present in the cache, we simply fetch the map and lookup the type.
This change improves the performance of encoding/decoding [N]byte.
name old time/op new time/op delta
DecodeByteArrayStruct-8 336ns ± 0% 246ns ± 0% -26.98% (p=0.000 n=9+10)
EncodeByteArrayStruct-8 225ns ± 1% 148ns ± 1% -34.12% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
DecodeByteArrayStruct-8 120B ± 0% 48B ± 0% -60.00% (p=0.000 n=10+10)
EncodeByteArrayStruct-8 0.00B 0.00B ~ (all equal)
This change grows the static integer buffer in Stream to 32 bytes, making it possible to decode 256bit integers without allocating a temporary buffer. In the recent commit 088da24, Stream struct size decreased from 120 bytes down to 88 bytes. This commit grows the struct to 112 bytes again, but the size change will not degrade performance because Stream instances are internally cached in sync.Pool. name old time/op new time/op delta DecodeBigInts-8 12.2µs ± 0% 8.6µs ± 4% -29.58% (p=0.000 n=9+10) name old speed new speed delta DecodeBigInts-8 230MB/s ± 0% 326MB/s ± 4% +42.04% (p=0.000 n=9+10)
Getting the raw value is not necessary to decode this type, and decoding it directly from the stream is faster.
| } | ||
| } | ||
| } | ||
| wg.Wait() |
There was a problem hiding this comment.
why wait here instead of line 1487
There was a problem hiding this comment.
I want to state.Commit and blockBatch.Write() run concurrently
| if data, ok := storage[storageHash]; ok { | ||
| snapshotDirtyStorageHitMeter.Mark(1) | ||
| snapshotDirtyStorageHitDepthHist.Update(int64(depth)) | ||
| //snapshotDirtyStorageHitDepthHist.Update(int64(depth)) |
There was a problem hiding this comment.
should we delete the comments here
There was a problem hiding this comment.
It is commented out because of the performance issue, if we need the metrics in some scenery, we get it back without deleting it.
| chainRules: chainConfig.Rules(blockCtx.BlockNumber), | ||
| interpreters: make([]Interpreter, 0, 1), | ||
| } | ||
| evm := EvmPool.Get().(*EVM) |
There was a problem hiding this comment.
where do we put the evm back to pool
eth/downloader/api.go
Outdated
| "sync" | ||
|
|
||
| "github.com/ethereum/go-ethereum/common/gopool" | ||
|
|
| // Issue the header retrieval request (absolute upwards without gaps) | ||
| go p.peer.RequestHeadersByNumber(from, count, 0, false) | ||
|
|
||
| go p.peer.RequestHeadersByNumber(from, count, 0, false) |
There was a problem hiding this comment.
It is used when clients doing fast sync and snap sync. Not related to performance
p2p/rlpx/rlpx.go
Outdated
| "github.com/ethereum/go-ethereum/rlp" | ||
| "github.com/golang/snappy" | ||
| "golang.org/x/crypto/sha3" | ||
| "github.com/oxtoacart/bpool" |
core/blockchain.go
Outdated
| } | ||
| if len(accountsSlice) >= preLoadLimit { | ||
| objsChan := make(chan []*state.StateObject, runtime.NumCPU()) | ||
| for i := 0; i < runtime.NumCPU(); i++ { |
There was a problem hiding this comment.
should we make sure that len(accountsSlice) > runtime.NumCPU()
There was a problem hiding this comment.
Add one more condition: len(accountsSlice) > runtime.NumCPU()
|
Can we get this PR merged? |

Description
This PR tries to improve the performance of BSC.
Rationale
Part of Block Processing can be parallel, and the layer of the snapshot is too deeper for the current implementation. This PR focus on:
Example
The testing result on an 8 core 2.5G Hz Linux VM:
Changes
New command flags:
--triesInMemoryPreflight checks
make build)make test)Already reviewed by
...
Related issues
... reference related issue #'s here ...