kadenzipfel/gas-optimizations

List of smart contract optimizations in solidity

gas-optimizations's Issues

Separate conditions instead of combined conditions

Should add a section on this to https://github.com/kadenzipfel/gas-optimizations/blob/main/gas-saving-patterns/short-circuiting.md with this to leave the reader with a fully optimized statement

e.g. use

if (condition) {
  if (anotherCondition) {
    ...
  }
}

over

if (condition && anotherCondition) {...}

works for &&/||

Enhance each optimization with further info

Each gas optimization should have this information:

• further knowledge links to understand why that change improves gas usage
• forge snapshot to compare A/B testing. How much gas are we going to get? People will also be able to test with different config (solidity version, compile flags and so on)
• With which solidity version and compiler flags these gas optimizations are true? From which Solidity version you can drop these "workarounds"?

Unlinked "see why" on Proper Data Types

On proper-data-types.md file, this item:

Type uint256 takes less gas to store than uint8 (see why).

has the "see why" part, which seems to be a forgotten link/reference.

Separate general gas saving patterns and technical patterns

imo there exist two types of gas saving patterns:

• general gas saving patterns, e.g. reducing logic in loops
• technical gas saving patterns, e.g. using assembly for specific actions

we should create corresponding sections to separate these concerns

Section on using assembly for gas savings

some things that can be added:

• use selfbalance opcode instead of address(this).balance
• use iszero opcode instead of if(x)
• https://twitter.com/clemlak/status/1521973218864771073?s=20&t=Bw97nieWjOAs4O2x2Kr8Tg
• etc

Use mulmod over mul & div

https://twitter.com/_hrkrshnn/status/1485023279186386961?s=20&t=XSGREAtikS_Bm1cojOmdfg

Include greater detail as to how gas is saved for technical patterns

for technical gas saving patterns, e.g. https://github.com/KadenZipfel/gas-optimizations/blob/main/gas-saving-patterns/optimal-comparison-operator.md, in which the pattern works because of a solidity compilation gotcha, the mechanism in which gas is saved should be better detailed, e.g. by explaining which opcodes are removed and why

Create docs book

using https://rust-lang.github.io/mdBook/

Immutable State Variables vs. Constant

I believe the example for this optimization is not completely correct. Immutable should be used when the state variable is assigned in the constructor. If it is directly assigned in the declaration, then constant should be used. Not sure if it affects the gas used (which is the point of the repo), but I think that the example could make the point better if it assigns the variable in the constructor.

Another idea would be to show both cases (constant and immutable) in that section.

++i vs i++

Yul IR pipeline

outline use of the new yul IR pipeline and how it may save gas
see: https://blog.soliditylang.org/2022/03/16/solidity-0.8.13-release-announcement/

Uint bit-packing

outline usage of bit-packing using uints directly

Payable constructor

The payable modifier can also help to reduce deployment costs. You can cut out 10 opcodes in the creation-time EVM bytecode if you declare a constructor payable. The following opcodes are cut out:

• CALLVALUE
• DUP1
• ISZERO
• PUSH2
• JUMPI
• PUSH1
• DUP1
• REVERT
• JUMPDEST
• POP

In Solidity, this chunk of assembly would mean the following:

if(msg.value != 0) revert();

I've compiled further gas optimisation tricks here.

Specify Solidity pragma in code snippets

Love this repository, but I think that there's an important piece of data missing from the code snippets: a Solidity pragma.

Gas costs differ between Solidity compiler versions, and in some cases the code may not even compile.

Conditional statement "!=" is not more gas efficient than ">" or ">="

Alleged Gas Costs

At the time of opening the issue, the Optimal Comparison Operator document makes the following claim:

In the case of a conditional statement, it is further optimal to use != when possible.

And then, the following gas costs are provided:

// 164 gas
function d() external pure {
  require(1 > 0);
}

// 208 gas
function e() external pure {
  require(1 >= 0);
}

// 120 gas
function f() external pure {
  require(1 != 0);
}

Actual Gas Costs

In the first example below, each function execution will consume exactly 21,162 gas (with the function compare per se consuming exactly 98 gas).

Try these on Remix with the optimizer enabled and set to 200 runs

1. Require example

pragma solidity =0.8.17;

contract A {
    function compare() external pure {
        require(1 > 0);
    }
}

contract B {
    function compare() external pure {
        require(1 >= 0);
    }
}

contract C {
    function compare() external pure {
        require(1 != 0);
    }
}

2. If/ else example

And in this case, the reported gasUsed will be 7.

pragma solidity =0.8.17;

contract A {
    function compare(uint256 x) external view returns (uint256 gasUsed) {
        uint256 startGas = gasleft();
        if (x >= 0) {
            uint256 foo = 1 + 2;
            foo;
        }
        gasUsed = startGas - gasleft();
    }
}

contract B {
    function compare(uint256 x) external view returns (uint256 gasUsed) {
        uint256 startGas = gasleft();
        if (x > 0) {
            uint256 foo = 1 + 2;
            foo;
        }
        gasUsed = startGas - gasleft();
    }
}

contract C {
    function compare(uint256 x) external view returns (uint256 gasUsed) {
        uint256 startGas = gasleft();
        if (x != 0) {
            uint256 foo = 1 + 2;
            foo;
        }
        gasUsed = startGas - gasleft();
    }
}

Possible Explanations

Let's start with this is what definitely isn't - this is not a matter of enabling the optimizer. Even with the optimizer disabled, the > 0 and != 0 checks cost the same in Solidity v0.8.17. That leaves with a couple of options left:

1. You defined all functions in the same contract, which made the 4-byte function signature add extra gas, depending upon the results of the keccak256 hsah.
2. Older compiler had different gas costs for these comparison operations? Unlikely, but possible.
3. Some other unintentional benchmarking/ instrumenting mistake.

Whatever the case, as discussed in #3 and #15, the best way to avoid situations like this in the future would be to document the methodology that you used to obtain the reported gas costs, so that others can repeat your process and catch mistakes more easily.

Examples with benchmarks for all gas saving patterns

we should make sure we have both:

• clear examples, and
• before and after gas benchmarks

for every gas saving pattern

Use do while if loop should run at least once

in general, do while loops are cheaper than for loops. as long as the loop is must run at least once, do while is preferred over for loops