...
In addition, the Besu team has been consistently working on enhancing the overall performance of the EVM. Engineering efforts from Hedera have focused mostly on non-storage related EVM performance. Most of these performance improvements came from re-writing core portions of the EVM with performance in mind instead of doing it "the right way" with standard and maintainable Java practices.
EVM Benchmarking
Improving performance without a consistent reference is akin to wandering in the desert at night: given enough time and space you will wind up where you started. A simple benchmarking suite called CartEVM (cartesian join + EVM) was written. For every operation it creates a state test that exercises the same operation as many times as possible with a minimum of other supporting operations. Executed with large contracts, at large gas limits, and executed inside a profiler has provided a wealth of optimization opportunities. Notable for CartEVM is that it can be configured to exercise all combinations of multiple opcodes exhaustively (the "cartesian join part") and that has unveiled some unexpected performance impacts.
Below is a summary table run with Java 21 on a M1 Mac Pro. Java 21 offers a 10-20% boost just for using it. Java 17 runs are more flat after 22.10.0 but are also lower than Java 21 runs in all cases. 5 runs of each operation were executed and the median and max values are shown. The results against all operations and a few select problematic values are averaged together to provide the number in this graph. There are two notable bumps on this graph, at 22.1.0 and 22.10.0, while the work after 22.10.0 have been focused on fixing some worst-case performance scenarios.
Native Types Transition
The first bump at 22.1.0 is mostly because of transitions from rich Java types for items such as Gas and transitioning stack items to simpler data types. This netted out to nearly doubling non-storage poritons of the EVM.
Inline EVM Operations Loop
The next large bump came in 22.10.0 with the introduciton of an inline operations loop. Prior to this all operations were subclasses of a single Operation class, and the loop selected an Operation object (following the Gang-of-four's Strategy pattern) and then called an overloaded method to execute the operation agains the current VM state. This "megamorphic method" is a know performance problem in "hot" java code, Java JITs work best against "monomoropic methods" where there is only one or two possible receivers per call site.
To address this dispatch problem all of the hight frequency operations were unwrapped into a single large switch statement, with each case statement calling a static form of the operation. The operations could still be used as virtual objects to build a custom VM based on the old pick and execute engine. Note that not all operations were unwrapped. More expensive and less frequently used operations didn't exhibit much performance improvement from unwrapping their dispatch into the switch.
Not hard-wiring in all operations also preserved important functionality for Hedera, Linea, and other downstream users of the EVM Library. Being able to override non-performance critical operations with operations more suitable for their use case increases the utility of EVM Equivelance in non-mainnet use cases.
Security-related Optimizations
Most of the jitter seen in the mast three quarterly releases are Jitter related to worst case performance scenarios predominantly found by Guido Vranken (not all findings published yet). Some of the best findings have come from his work in Fuzzing multiple EVM implementations and sharing the slow executing cases. While these cases are not typical in mainnet use (otherwise we would have seen them before) they could easily be used as an attack to slow down Besu nodes and in extreme cases stall networks. This work also helped fill out missing features from the Besu EVM Fluent AIPs.
Commit phase improvements
...