core/vm: `codeBitmap` is consuming ~20% of CPU time in simulation heavy workloads

[lmittmann]

Rationale

codeBitmap is consuming ~20% of CPU time when the EVM is used in simulation heavy workloads. Currently the result of codeBitmap is cached in a map for each distinct codeHash for the lifetime of the core.EVM struct.

Example Benchmark

Implementation

I propose to abstract map[common.Hash]bitvec in vm.EVM to an interface type:

type JumpDests interface {
    Load(codeHash common.Hash) (BitVec, bool)
    Store(codeHash commonHash, vec BitVec)
}

And to give the EVM an option to set jumpDests in vm.NewEVM.

This abstraction gives the flexibility to both keep the current logic of creating a separate store for each EVM instance, as well as using a global thread safe store (e.g. lru-cache).

[rjl493456442]

Sounds like a useful optimization to me. Will discuss with team at today's Triage.

[fjl]

Sounds like a good idea. Would be great if this benefits our own performance as well. @lmittmann do you have time to implement this?

[lmittmann]

Yes. Although I am not sure about the best way to make geth benefit. The question is: what is a good cache size? It is not the kind of thing I would want the user to set via a CLI flag. Wdyt?

[juga1980]

jumpDests map is started with capacity 0 in New-Constructor, so every insert could make a new dynamic reallocation to a new map, and that can cost. Other languages like java/c++ starts with capacity 16 and doubles that, if reached. It is only modified in contract.go, so a improvement could be done there locally.