What foundry profiles should we have?

[andreivladbrg]

In v2-core, the reasons behind the optimized profile structure is that we need to run contracts with via_ir - otherwise, the contracts would exceed the maximum contract size limit of approximately 24kb. Also because we faced issues with the "stack too deep" error.

Lockup contracts compiled with the default profile

For the OE contract, it is still far from reaching the contract size limit:

OE contract compiled with the default profile

Benefits of having the same profile structure:

• it will slightly optimize the contract, but only if we set the optimizer runs to a much higher number than 1000.

Cons:

• quote from cameel: "the performance is still not good enough"
• it will increase the complexity of the project and slow down the development process

My recommendation is to keep only the default profile for now and see how the development process go.

What do you say? @sablier-labs/solidity

[PaulRBerg]

I do not fully understand your argument. Also, the quote from Cameel is out of context. Where did he say that? And did he say in response to what?

Is your point that via IR would lead to a small reduction in bytecode size and/ or gas costs? If yes, can quantify this claim?

I don't see how using via IR would slow down the development process locally. For that, we're using the lite profile anyway. Via IR only slows down CI.

[smol-ninja]

It will slightly optimize the contract, but only if we set the optimizer runs to a much higher number than 1000

I did not understand why having the same profile structure offers a more optimized contract. Can you please elaborate more on this?

As per the Solidity doc, the number of runs determines whether the contract would be optimized for execution runs or deployment. There is a trade-off between the two but having a higher number favours cheaper interactions with the contract. Based on this information, it is useful to have optimizer enabled.

I am not completely sure whether we should enable via_ir or not. I suggest we benchmark it and see which produces more efficient code.

We would still need two profiles at the minimum:

1. default with optimizer enabled.
2. lite to speed up the development.

Other profiles:

• test-optimized: useful if we need ffi which is still required for deterministic deployment
• default.fuzz: Do we use it in core?
• default.invariant: Do we use it in core?
• profile.smt: unsure about it. Are they still being used in core?

[PaulRBerg]

Agree with the overall rationale. Let me just answer this:

default.fuzz and default.invariant are not different profile. They are the same profile default. This is just TOML syntactic sugar to avoid creating nested fuzz and invariant objects within default.

profile.smt - let's keep it. It may be useful for auditors.

[smol-ninja]

Alright. Thanks for the explaination.

[smol-ninja]

@andreivladbrg would love to hear your take in case you have changed your mind about it as well?

[andreivladbrg]

Also, the quote from Cameel is out of context. Where did he say that? And did he say in response to what?

The quote from Cameel is from this post. The point I was trying to make with "performance" is that it takes way more time to compile the contracts with via_ir.

Is your point that via IR would lead to a small reduction in bytecode size and/ or gas costs? If yes, can quantify this claim?

My point is that the contract size would be smaller with via_ir = true - not needed since we are far from exceeding the limit size (see test below). Regarding the gas costs I was referring to the optimizer_runs.

Via IR only slows down CI.

that is correct, but it would increase the complexity of the project when it is not needed:

• adding more profiles (profile.optimized & profile.test-optimized)
• helper functions in tests to determine the profile which the tests are run on
• Precompiles & Precompiles tests

---

test did on this commit: cbc378d
With via_ir = true & optimizer_runs = 10_000:

[⠘] Compiling 73 files with 0.8.23
[⠃] Solc 0.8.23 finished in 162.53s
| Contract.          | Size (B) | Margin (B) |
| SablierV2OpenEnded | 10974    | 13602      |

With via_ir = false & optimizer_runs = 10_000:

[⠑] Compiling 73 files with 0.8.23
[⠃] Solc 0.8.23 finished in 11.03s
| Contract.          | Size (B) | Margin (B) |
| SablierV2OpenEnded | 12255    | 12321      |

With via_ir = false & optimizer_runs = 1_000:

[⠑] Compiling 73 files with 0.8.23
[⠃] Solc 0.8.23 finished in 10.94s
| Contract.          | Size (B) | Margin (B) |
| SablierV2OpenEnded | 10567    | 14009      |

as you can see, there is 2.5 minutes difference between via_ir true/false

---

I did not understand why having the same profile structure offers a more optimized contract. Can you please elaborate more on this?

It was also a mistake on my part that I forgot the optimizer is already activated in the default profile. Setting optimizer_runs = 10_000 can be more gas-efficient than optimizer_runs = 1_000, but it would produce a larger contract size. This is because a higher optimizer_runs setting increases the contract size.

https://github.com/sablier-labs/v2-open-ended/blob/1391fe9880a374875f1e0d7d243872836ff20150/foundry.toml#L10-L11

Conclusion

My conclusion is that we don't need via_ir, since we don't have a problem with the contract's size nor with the "Stack too deep" error. To the current setup, we could add the lite profile, which simply sets optimizer_runs to false.

[PaulRBerg]

Two points:

1. What's the cost of deploying $12255-10974=1281$ bytes on Mainnet?
   • If it's high, we will keep using via IR.
   • If it's low, we will not use via IR.
2. Weren't we brainstorming to move this contract to the future core repository (after package tethering gets implemented)? If we move it there, we will have to use via IR because the Lockup contracts need that.

[andreivladbrg]

What's the cost of deploying bytes on Mainnet?

Mainnet via_ir = true: https://app.warp.dev/block/ujmKMildIzSSmmlOInQVVC

Mainnet via_ir = false: https://app.warp.dev/block/a3OnRvJkaqfakuMgadcEE3

at the current gas price the difference is: $\ 0.045764375209569252 - 0.04112374237417832 = 0.00464063283 ETH $

which results (at the current ETH price) in: $\ 3032 * 0.00464063283 = 14.0703987406 USD $

IMO it is a small difference (for mainnet)

Weren't we brainstorming to move this contract to the future core repository (after package tethering gets implemented)? If we move it there, we will have to use via IR because the Lockup contracts need that

I don't remember agreeing to or making a decision on that, which I consider not a good idea since we kinda decided to rename the v2-core + v2-periphery repo to evm-lockup or sablier-lockup. Also, we would need diferent packages versions.

[smol-ninja]

Thanks for the thorough analysis @andreivladbrg. This is indeed very helpful. I had some questions that I also tried to answer below:

1. What is the concern with higher compile time with via_ir = true?

   The optimized build is supposed to be for production CI and not for testing. During development, we will have the lite profile i.e. via_ir = false and optimizer_runs = 1000.

   Also the compile time depends on the machine too. For ex. in my case it takes 80s.

2. Does via_ir have any impact on execution costs of functions?

   I was curious to find out if via_ir has any impact on execution cost. We are already aware that higher the optimizer_runs, more efficient executions are. So, I discovered that having via_ir = true also optimizes the executions.

via_ir = true and optimizer_runs = 10000
=> contract size: 10,515 B
=> create gas: 103,665
=> build time: 83.82s

via_ir = true and optimizer_runs = 1000
=> contract size: 8,547 B
=> create gas: 103,809
=> build time: 82.68s

via_ir = false and optimizer_runs = 10000
=> contract size: 11,912 B
=> create gas: 104,973
=> build time: 6.91s

via_ir = false and optimizer_runs = 1000
=> contract size: 10,174 B
=> create gas: 105,081
=> build time: 7.03s

You can see that the via_ir reduces the gas by 1.24%. Inspite of it being so small, over a very long period of time, the cumulative extra gas consumed because of via_ir = false could be significant.

So its a trade off between execution costs (and contract size) and production build time.

[andreivladbrg]

So, I discovered that having via_ir = true also optimizes the executions

Oh, nicee, I was not aware of this. Thanks for the test.

In this case I changed my mind, we should have the via_ir = true.

[PaulRBerg]

Fantastic sleuthing @smol-ninja.

[andreivladbrg]

Ok, since we all agreed on having the via_ir = true we can close this discussion.

Thank you both for your kind comments.

[PaulRBerg]

Thank you for changing your mind