Gas Optimizations #24
Labels
bug
Something isn't working
G (Gas Optimization)
resolved
Finding has been patched by sponsor (sponsor pls link to PR containing fix)
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Catching The Array Length Prior To Loop
Context:
RoleManager.sol#L75-L88
,RewardHandler.sol#L35-L55
,StakerVault.sol#L256-L263
,FeeBurner.sol#L43-L88
,InflationManager.sol#L110-L125 (For L116)
,VestedEscrow.sol#L89-L111
,PoolMigrationZap.sol#L20-L29
,PoolMigrationZap.sol#L38-L45
Description:
One can save gas by caching the array length (in stack) and using that set variable in the loop. Replace state variable reads and writes within loops with local variable reads and writes. This is done by assigning state variable values to new local variables, reading and/or writing the local variables in a loop, then after the loop assigning any changed local variables to their equivalent state variables.
Recommendation:
Simply do something like so before the for loop:
uint length = variable.length
. Then addlength
in place ofvariable.length
in the for loop.In
require()
, Use!= 0
Instead of> 0
With Uint ValuesContext:
BkdLocker.sol#L90-L100 (For both)
,BkdLocker.sol#L133-L155 (For L137)
,AmmGauge.sol#L103-L116 (For L104)
,AmmGauge.sol#L124-L138 (For L125)
,KeeperGauge.sol#L125-L144 (For L140)
,VestedEscrow.sol#L80-L87 (For L84)
Description:
In a require, when checking a uint, using
!= 0
instead of> 0
saves 6 gas. This will jump over or avoid an extraISZERO
opcode.Recommendation:
Use
!= 0
instead of> 0
with uint values but only inrequire()
statements.Setting The Constructor To Payable
Context:
All Contracts
Description:
You can cut out 10 opcodes in the creation-time EVM bytecode if you declare a constructor payable. Making the constructor payable eliminates the need for an initial check of
msg.value == 0
and saves 21 gas on deployment with no security risks.Recommendation:
Set the constructor to payable.
Function Ordering via Method ID
Context:
All Contracts
Description:
Contracts most called functions could simply save gas by function ordering via Method ID. Calling a function at runtime will be cheaper if the function is positioned earlier in the order (has a relatively lower Method ID) because 22 gas are added to the cost of a function for every position that came before it. The caller can save on gas if you prioritize most called functions. One could use
This tool
to help find alternative function names with lower Method IDs while keeping the original name intact.Recommendation:
Find a lower method ID name for the most called functions for example
mostCalled()
vs.mostCalled_41q()
is cheaper by 44 gas.The text was updated successfully, but these errors were encountered: