Gas Optimizations #139
Labels
Comments
|
This was a very thorough gas optimization report and is very helpful for us. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Table of Contents:
BalancerV2LPOracle.sol: Tighly pack storage variables> 0is less efficient than!= 0for unsigned integers (with proof)<=is cheaper than<require()statements that use&&saves gasrequire()should be used for checking error conditions on inputs and return values whileassert()should be used for invariant checking++icosts less gas compared toi++ori += 1Help the optimizer by saving a storage variable's reference instead of repeatedly fetching it
To help the optimizer, declare a
storagetype variable and use it instead of repeatedly fetching the reference in a map or an array.The effect can be quite significant.
As an example, instead of repeatedly calling
someMap[someIndex], save its reference like this:SomeStruct storage someStruct = someMap[someIndex]and use it.Instances include (check the
@audittags):Caching external values in memory
See the
@audittags for further details:Using an existing memory variable instead of reading storage
See the
@audittags for further details:BalancerV2LPOracle.sol: Tighly pack storage variablesI suggest going from (see
@audittags):to
Which would save 1 storage slot.
Variables that should be constant
According to slither:
> 0is less efficient than!= 0for unsigned integers (with proof)!= 0costs less gas compared to> 0for unsigned integers inrequirestatements with the optimizer enabled (6 gas)Proof: While it may seem that
> 0is cheaper than!=, this is only true without the optimizer enabled and outside a require statement. If you enable the optimizer at 10k AND you're in arequirestatement, this will save gas. You can see this tweet for more proofs: https://twitter.com/gzeon/status/1485428085885640706I suggest changing
> 0with!= 0here:Also, please enable the Optimizer.
<=is cheaper than<Strict inequalities (
<) are more expensive than non-strict ones (<=). This is due to some supplementary checks (ISZERO, 3 gas)I suggest using
<=instead of<here:Splitting
require()statements that use&&saves gasInstead of using the
&&operator in a single require statement to check multiple conditions, I suggest using multiple require statements with 1 condition per require statement (saving 3 gas per&):require()should be used for checking error conditions on inputs and return values whileassert()should be used for invariant checkingProperly functioning code should never reach a failing assert statement, unless there is a bug in your contract you should fix. Here, I believe the assert should be a require or a revert:
As the Solidity version is
0.6.12 < 0.8.0, the remaining gas would not be refunded in case of failure.Amounts should be checked for 0 before calling a transfer
Checking non-zero transfer values can avoid an expensive external call and save gas.
While this is done at some places, it's not consistently done in the solution.
I suggest adding a non-zero-value check here:
An array's length should be cached to save gas in for-loops
Reading array length at each iteration of the loop takes 6 gas (3 for mload and 3 to place memory_offset) in the stack.
Caching the array length in the stack saves around 3 gas per iteration.
Here, I suggest storing the array's length in a variable before the for-loop, and use it instead:
++icosts less gas compared toi++ori += 1++icosts less gas compared toi++ori += 1for unsigned integer, as pre-increment is cheaper (about 5 gas per iteration). This statement is true even with the optimizer enabled.i++incrementsiand returns the initial value ofi. Which means:But
++ireturns the actual incremented value:In the first case, the compiler has to create a temporary variable (when used) for returning
1instead of2Instances include:
I suggest using
++iinstead ofi++to increment the value of an uint variable.Usage of a non-native 256 bits uint as a counter in for-loops increases gas cost
Due to how the EVM natively works on 256 bit numbers, using a 8 bit number in for-loops introduces additional costs as the EVM has to properly enforce the limits of this smaller type.
See the warning at this link: https://docs.soliditylang.org/en/v0.8.0/internals/layout_in_storage.html#layout-of-state-variables-in-storage :
Affected code:
Consider manually checking for the upper bound before the for-loop and using the
uint256type as a counter in the mentioned for-loops.Public functions to external
The following functions could be set external to save gas and improve code quality.
External call cost is less expensive than of public functions.
No need to explicitly initialize variables with default values
If a variable is not set/initialized, it is assumed to have the default value (
0foruint,falseforbool,address(0)for address...). Explicitly initializing it with its default value is an anti-pattern and wastes gas.As an example:
for (uint256 i = 0; i < numIterations; ++i) {should be replaced withfor (uint256 i; i < numIterations; ++i) {Instances include:
I suggest removing explicit initializations for default values.
Use Custom Errors instead of Revert Strings to save Gas
Custom errors from Solidity 0.8.4 are cheaper than revert strings (cheaper deployment cost and runtime cost when the revert condition is met)
Source: https://blog.soliditylang.org/2021/04/21/custom-errors/:
Custom errors are defined using the
errorstatement, which can be used inside and outside of contracts (including interfaces and libraries).Instances include:
I suggest replacing revert strings with custom errors.
The text was updated successfully, but these errors were encountered: