Optimizer runs - we can't always get what we want

[PaulRBerg]

Context

We currently have the --optimizer-runs config option set to 10,000:

v2-core/foundry.toml

Line 16 in 4918aca

optimizer_runs = 10_000

What we want

The number of optimizer runs should be set according to how many times the developer expects the contract to be called. To quote the Solidity docs on this topic:

The number of runs specifies roughly how often each opcode of the deployed code will be executed across the life-time of the contract

The Sablier V2 lockup contracts are "singletons" - they contain both storage and functionality, and are expected to be the main points of entry into the protocol. Assuming Sablier V2 is successful, the contracts will be called a great many number of times. Thus, we would ideally set the number of optimizer runs to the maximum value allowed, which is $2^{32}-1$, just like Seaport does.

What we can get

Unfortunately, as discussed at point 8 in #279, a high number of optimizer runs significantly increases the size. Using commit 9fa613f1 and setting the optimizer_runs config option to $2^{32}-1$, I have obtained a size of ~29kB for the pro contract, which is ~4.5kB over the ~24.5kB limit.

Again, to quote the Solidity docs:

This means it is a trade-off parameter between code size (deploy cost) and code execution cost (cost after deployment). A “runs” parameter of “1” will produce short but expensive code. In contrast, a larger “runs” parameter will produce longer but more gas efficient code.

Note about Yul IR

We are also using the Yul IR optimizer (--via-ir), so I am not sure we actually want to bump the optimizer runs to the maximum value possible. I have posted this as a question on Twitter, and I may also follow up in the Solidity server if I don't get a good response on Twitter.

[PaulRBerg]

Benchmarks

I have run some benchmarks against commit e8b3a93e.

1,000 runs

Link to GitHub Gist with gas snapshot for 1,000 optimizer runs.

5,000 runs

Link to GitHub Gist with gas snapshot for 5,000 optimizer runs.

10,000 runs (current setting)

Link to GitHub Gist with gas snapshot for 10,000 optimizer runs.

50,000 runs

Link to GitHub Gist with gas snapshot for 50,000 optimizer runs.

4,294,967,295 runs

Link to GitHub Gist with gas snapshot for 4,294,967,295 optimizer runs.

Benchmark for the Withdraw Function

The withdraw function will be the most used function in the protocol, so I used it as a yardstick to compare the gas optimizations brought about by tweaking the number of optimizer runs.

Optimizer Runs	Average (μ)	Median (~)
1,000	349,433	337,617
5,000	348,638	336,966
10,000	347,652	336,198
50,000	347,224	335,340
4,294,967,295	346,887	335,328

Side Note

Unfortunately, there is a bug in the forge snapshot command (which I reported here), which causes duplicate contract names to appear in the report - my guess is that this is due to Foundry making a resolution starting from the test function names (which are the same in our case between the shared linear and pro tests), and associating only one contract with one given function name. However, this bug shouldn't affect our ability to make a decision based on the results obtained. We can still reason about specific gas costs.

[PaulRBerg]

Locking, ended up sticking with 5,000 runs.

6848204