Gas Optimizations #5
Labels
Comments
|
QA & gas optimizations changes are done in the PR: PaladinFinance/Paladin-Tokenomics#6 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Gas Report
Table of Contents:
> 0is less efficient than!= 0for unsigned integers (with proof)Foreword
@audittagsFindings
Storage
Help 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):This is a known practice in the same contract, as several
UserLock storage currentUserLockare declared and used instead of repeatedly fetching the struct's reference.Caching storage values in memory
The code can be optimized by minimising the number of SLOADs. SLOADs are expensive (100 gas) compared to MLOADs/MSTOREs (3 gas). Here, storage values should get cached in memory (see the
@audittags for further details):Variables
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.Instances include:
I suggest removing explicit initializations for default values.
Variable that should be constant
This variable is never updated. It should be declared as constant:
Comparisons
> 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.
Arithmetics
Unchecking arithmetics operations that can't underflow/overflow
Solidity version 0.8+ comes with implicit overflow and underflow checks on unsigned integers. When an overflow or an underflow isn't possible (as an example, when a comparison is made before the arithmetic operation), some gas can be saved by using an
uncheckedblock: https://docs.soliditylang.org/en/v0.8.10/control-structures.html#checked-or-unchecked-arithmeticI suggest wrapping with an
uncheckedblock here (see@audittags for more details):Shift Right instead of Dividing by 2
A division by 2 can be calculated by shifting one to the right.
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.I suggest replacing
/ 2with>> 1here:Errors
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. They are already used in the solution but not extensively.
The text was updated successfully, but these errors were encountered: