Speed of RPC execution - speed of estimate gas execution - number of ethclient handles

[fxfactorial]

Several questions of which its hard to find any notes about

Looking for insight into how to increase the speed of execution of RPC calls - that is - does the size of the txn pool have any bearing on how quickly the RPC calls go through ? (assume IPC connection used) (wondering if dropping in https://github.com/valyala/fastjson would increase speed)

Or does the size of the txn pool have any bearing on the speed at which estimate gas goes through - is there any tip/trick to make estimate gas go faster? why is it so slow

What about the number of ethclient handles made? Is it better to have one handle with many queries that hit it up or to have many ethclients ?

[holiman]

More info about eth calls in general can be found here: #21772

[ligi]

The bottleneck is most likely the EVM execution. Gas estimation is basically doing a binary search to find the smallest gas price where the tx still succeeds. Things like JSON parsing are not really relevant performance wise here.
We do not really see ways to improve the situation. Ideas welcome - otherwise we can just recommend more computing power.
If you see it differently please provide us with numbers/benchmarks.

[fxfactorial]

@ligi do you mean the loop run in (Interpreter).Run()? that is, the majority of time spent is there

[MariusVanDerWijden]

Which loop are you referring too? core/vm/interpreter.go:210 ? This is the main loop of the EVM that executes the opcodes of the smart contract. So this is the most compute intensive loop and by far the biggest holdup which can not be optimized away of course.

[holiman]

This isn't really a bug report, rather a pretty vague set of questions, which have been mostly answered. Closing