Why in solidity, i++ & ++i works the same but one costs a little bit more gas?

Take a look at this contract:

contract foobar {
    uint[] public arr = [1,2,3,4,5];

    function find() public view returns(bool) {
            for(uint i = 0; i < arr.length; i++ /*++i*/) {
            if(arr[i] == 5) {
                return true;
        return false;

When I run this contract using i++ this is what the contract's cost is:

// i++
// gas  388824 gas
// transaction cost 338107 gas 
// execution cost   338107 gas 
// foobar.find() execution cost 36221 gas

And when I run the same function using ++i, this is what the cost is:

// ++i
// gas  388327 gas
// transaction cost 337675 gas 
// execution cost   337675 gas
// foobar.find() execution cost 36201 gas

Clearly, i++ costs more gas than ++i, But Why? Thanks

  • 5
    Pre-increment and post-increment usually result in slightly different execution steps, this is not unique to Solidity. Related: What is the difference between ++i and i++?
    – Mast
    Aug 7 at 18:18
  • 1
    Newer versions of solidity should optimize this. In the past, the difference could be attributed to the codegen for i++ not getting inlined. Try --via-ir with the optimizer, they should have identical gas cost, except when the semantics are different.
    – hrkrshnn
    Aug 9 at 18:28

1 Answer 1


They do not work the same. i++ gets compiled to something like

j = i;
i = i + 1;
return j

while ++i gets compiled to something like

i = i + 1;
return i;

Long story short, i++ returns the non-incremented value, and ++i returns the incremented value, so for example, doing

i = 0;

will access the value at index 0 in the array, while array[++i] will access the value at index 1.

  • 1
    +1 for "They do not work the same.". [Too] Many people make this mistake.
    – Phill W.
    Aug 8 at 11:27
  • 7
    Though you'd expect most modern compilers to be able to automatically optimise i++ into the same operations as ++i if the value of the expression is not actually being used like in the OPs example... Aug 8 at 11:44
  • 1
    this is the kind of thing an optimizing compiler could reasonably be expected to optimize tho.. for example gcc auto-optimize this on -O2 and -Og but not -O0 - notably the PHP language does not optimize this at all (:
    – hanshenrik
    Aug 8 at 13:21
  • 4
    Relevant Google-able terms are "prefix operator" (++i) and "postfix operator" (i++) operator. For completeness: there's also an "infix operator" (i + 1).
    – minnmass
    Aug 8 at 13:48
  • 2
    @SeanBurton does Ethereum use dumb compilers on purpose for security? optimizations have created wrong code and security vulnerabilities before
    – user253751
    Aug 8 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.