Gas Optimizations #158
Labels
bug
Something isn't working
duplicate
This issue or pull request already exists
G (Gas Optimization)
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Gas Optimizations Report
For-loops: Index initialized with default value
Uninitialized
uintvariables are assigned with a default value of0.Thus, in for-loops, explicitly initializing an index with
0costs unnecesary gas. For example, the following code:can be changed to:
Consider declaring the following lines without explicitly setting the index to
0:For-Loops: Cache array length outside of loops
Reading an array length at each iteration of the loop takes 6 gas (3 for
mloadand 3 to placememory_offset) in the stack.Caching the array length in the stack saves around 3 gas per iteration.
For example:
can be changed to:
Consider making the following change to these lines:
For-Loops: Index increments can be left unchecked
From Solidity v0.8 onwards, all arithmetic operations come with implicit overflow and underflow checks.
In for-loops, as it is impossible for the index to overflow, it can be left unchecked to save gas every iteration.
For example, the code below:
can be changed to:
Consider making the following change to these lines:
Arithmetics:
++icosts less gas compared toi++ori += 1++icosts less gas compared toi++ori += 1for unsigned integers, 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 of2, thus it costs more gas.The same logic applies for
--iandi--.Consider using
++iinstead ofi++ori += 1in the following instances:Arithmetics: Use
!= 0instead of> 0for unsigned integersuintwill never go below 0. Thus,> 0is gas inefficient in comparisons as checking if!= 0is sufficient and costs less gas.Consider changing
> 0to!= 0in these lines:Arithmetics: Use Shift Right/Left instead of Division/Multiplication if possible
A division/multiplication by any number
xbeing a power of 2 can be calculated by shiftinglog2(x)to the right/left.While the
DIVopcode uses 5 gas, theSHRopcode only uses 3 gas. Furthermore, Solidity's division operation also includes a division-by-0 prevention which is bypassed using shifting.For example, the following code:
can be changed to:
Consider making this change to the following lines:
Visibility: Consider declaring constants as non-public to save gas
If a constant is not used outside of its contract, declaring it as
privateorinternalinstead ofpubliccan save gas.Consider changing the visibility of the following from
publictointernalorprivate:Visibility:
publicfunctions can be set toexternalCalls to
externalfunctions are cheaper thanpublicfunctions. Thus, if a function is not used internally in any contract, it should be set toexternalto save gas and improve code readability.Consider changing following functions from
publictoexternal:Errors: Reduce the length 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.In these instances, consider shortening the revert strings to fit within 32 bytes, or using custom errors:
Errors: Use custom errors instead of revert strings
Since Solidity v0.8.4, custom errors should be used instead of revert strings due to:
Taken from Custom Errors in Solidity:
Custom errors can be defined using of the
errorstatement, both inside or outside of contracts.Instances where custom errors can be used instead:
Unecessary initialization of variables with default values
Uninitialized variables are assigned with a default value depending on its type:
uint:0bool:falseaddress:address(0)Thus, explicitly initializing a variable with its default value costs unnecesary gas. For example, the following code:
can be changed to:
Consider declaring the following lines without explicitly setting a value:
Unnecessary definition of variables
Some variables are defined even though they are only used once in their respective functions. Not defining these variables can help to reduce gas cost and contract size.
Instances include:
Storage variables should be declared
immutablewhen possibleIf a storage variable is assigned only in the constructor, it should be declared as
immutable. This would help to reduce gas costs as calls toimmutablevariables are much cheaper than regular state variables, as seen from the Solidity Docs:Consider declaring these variables as
immutable:Boolean comparisons
Comparing to a constant (
trueorfalse) is a bit more expensive than directly checking the boolean value.Considering changing the following lines from
var == truetovar, orvar == falseto!var:Variables declared as
constantare expressions, not constantsDue to how
constantvariables are implemented (replacements at compile-time), an expression assigned to aconstantvariable is recomputed each time that the variable is used, which wastes some gas.If the variable was
immutableinstead: the calculation would only be done once at deploy time (in the constructor), and then the result would be saved and read directly at runtime rather than being recalculated.See: ethereum/solidity#9232:
Change these expressions from
constanttoimmutableand implement the calculation in the constructor. Alternatively, hardcode these values in the constants and add a comment to say how the value was calculated.The text was updated successfully, but these errors were encountered: