5

When enabling the optimizer the documentation of solc tells you that you can choose between optimizing the gas cost at deployment or the gas cost at execution by setting the runs parameter.

But what is the default behavior when the optimizer is disabled? Will the compiled bytecode lead to high gas cost of deployment AND high gas cost fo execution, or can we assume that it leads by default to high gas cost of deployment but low for gas cost of execution?

Rick Park
  • 3,194
  • 2
  • 8
  • 25
juniz
  • 139
  • 8
  • It's probably equivalent to optimize=false AND runs=0, so you can do the math from here ((i.e., if increasing runs reduces execution gas cost, then decreasing runs will enlarge execution gas cost). – goodvibration Jan 21 '19 at 09:30

1 Answers1

5

The default is “I do not care about gas consumption, not when deploying and not when running. Just give me a bytecode easy to debug.”

As a matter of fact the code size shall be bigger than the minimum and the execution cost shall be bigger than the minimum, but the mapping from source code to bytecode shall be as detailed and straight and clear as it can be.

“Runs” can be interpreted as the expected number of runs of the deployed code in the whole life of the contract to be optimized.

If you specify Runs=10 it means that any optimization that make it globally less costly to deploy and run ten times the code are allowed. And this can be very different than optimize one deploy and 1000 executions!

Rick Park
  • 3,194
  • 2
  • 8
  • 25
  • is there any risk to using any optimization available? – Megan Aug 21 '20 at 16:19
  • Two answer: 1) Nobody truly knows it before testing. Usually you have a set of tests to check your code. You can run them before the optimization and after and you should find the same results. 2) Usually the optimizer has been debugged very much before release it, usually it works very well. – Rick Park Aug 21 '20 at 23:25
  • 1
    @Megan, yes there can be risks: https://blog.ethereum.org/2017/05/03/solidity-optimizer-bug/ – Tim Daubenschütz Feb 06 '22 at 14:15