Gas Optimizations #70
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")
Comments
chase-manning
added
sponsor confirmed
Cheap Contract Deployment Through ClonesAgree but in lack of gas comparison I can't quantify > 0 is less efficient than != 0 for unsigned integers (with proof)Valid because of Solidity < 0.8.13 on require with optimizer An array's length should be cached to save gas in for-loopsValid as it saves reading the offset ++i costs less gas compared to i++ or i += 1 (same for --i vs i-- or i -= 1)10 gas saved Increments can be unchecked in for-loopsAgree, would save 20 gas No need to explicitly initialize variables with default valuesSaves 3 gas Reduce the size of error messages (Long revert Strings)6 gas Use Custom Errors instead of Revert Strings to save GasIn lack of POC I can't quantify the savings Pretty well-written report, missing just a couple of extra tests to make it shine Total Gas Saved |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Table of Contents:
> 0is less efficient than!= 0for unsigned integers (with proof)++icosts less gas compared toi++ori += 1(same for--ivsi--ori -= 1)Cheap Contract Deployment Through Clones
See
@audittag:There's a way to save a significant amount of gas on deployment using Clones: https://www.youtube.com/watch?v=3Mw-pMmJ7TA .
This is a solution that was adopted, as an example, by Porter Finance. They realized that deploying using clones was 10x cheaper:
I suggest applying a similar pattern.
> 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.
An array's length should be cached to save gas in for-loops
Reading array length at each iteration of the loop consumes more gas than necessary.
In the best case scenario (length read on a memory variable), caching the array length in the stack saves around 3 gas per iteration.
In the worst case scenario (external calls at each iteration), the amount of gas wasted can be massive.
Here, I suggest storing the array's length in a variable before the for-loop, and use this new variable instead:
++icosts less gas compared toi++ori += 1(same for--ivsi--ori -= 1)Pre-increments and pre-decrements are cheaper.
For a
uint256 ivariable, the following is true with the Optimizer enabled at 10k:Increment:
i += 1is the most expensive formi++costs 6 gas less thani += 1++icosts 5 gas less thani++(11 gas less thani += 1)Decrement:
i -= 1is the most expensive formi--costs 11 gas less thani -= 1--icosts 5 gas less thani--(16 gas less thani -= 1)Note that post-increments (or post-decrements) return the old value before incrementing or decrementing, hence the name post-increment:
However, pre-increments (or pre-decrements) return the new value:
In the pre-increment case, the compiler has to create a temporary variable (when used) for returning
1instead of2.Affected code:
Consider using pre-increments and pre-decrements where they are relevant (meaning: not where post-increments/decrements logic are relevant).
Increments can be unchecked in for-loops
In Solidity 0.8+, there's a default overflow check on unsigned integers. It's possible to uncheck this in for-loops and save some gas at each iteration, but at the cost of some code readability, as this uncheck cannot be made inline.
ethereum/solidity#10695
Affected code:
The change would be:
The risk of overflow is non-existant for
uint256here.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) {Affected code:
I suggest removing explicit initializations for default values.
Reduce the size of error messages (Long revert Strings)
Shortening revert strings to fit in 32 bytes will decrease deployment time gas and will decrease runtime gas when the revert condition is met.
Revert strings that are longer than 32 bytes require at least one additional mstore, along with additional overhead for computing memory offset, etc.
Revert strings > 32 bytes:
I suggest shortening the revert strings to fit in 32 bytes.
Use Custom Errors instead of Revert Strings to save Gas
Solidity 0.8.4 introduced custom errors. They are more gas efficient than revert strings, when it comes to deploy cost as well as runtime cost when the revert condition is met. Use custom errors instead of revert strings for gas savings.
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).I suggest replacing all revert strings with custom errors in the solution.
The text was updated successfully, but these errors were encountered: