Reuse optimized IR for bytecode dependencies

cameel commented 3 weeks ago

The quick and easy solution for #15179, which only reuses the IR.

cameel commented 3 weeks ago

Benchmarks on external projects:

Project	v0.8.26	This PR	Speedup
openzeppelin	40 s	36 s	10%
uniswap-v4	177 s	116 s	34%

Script that I used for benchmarking: #15183.

cameel commented 3 weeks ago

Here's some more benchmarking with #15183:

Project	legacy	IR (0.8.26)	IR (this PR)	Speedup
openzeppelin	10 s	41 s	36 s	12%
uniswap-v4	22 s	259 s	140 s	46%
eigenlayer	80 s	1324 s	622 s	53%
sablier-v2	153 s	1952 s	889 s	54%

Some important notes:

This time the numbers are averages from several runs. The small difference for OZ is actually reproducible and not just a fluke.
The previous results for Uniswap were on a commit from 2024-05-10. I updated to 2024-06-06 before this benchmark and apparently it now compiles a lot slower even with a release binary. I think they must have added more tests. Still, this seems to make the effect of the PR even more pronounced.
Sablier fails with StackTooDeep when compiled via IR. I still included it because this seems to happen towards the end compilation and the result seems in line with the other projects in the table, all of which did complete without errors.

cameel commented 3 weeks ago

And here is the timing from external tests (extracted using the script from https://github.com/ethereum/solidity/pull/15023#issuecomment-2067151960):

Project	Before	After	Diff
brink	4 s	4 s	0 s
colony	100 s	99 s	-1 s
elementfi	98 s	82 s	-16 s
ens	26 s	35 s	9 s
euler	30 s	32 s	2 s
gnosis
gp2	38 s	30 s	-8 s
pool-together	35 s	33 s	-2 s
uniswap	47 s	37 s	-10 s
yield_liquidator	22 s	22 s	0 s
zeppelin	177 s	149 s	-28 s

They numbers don't seem particularly reliable though. For example the longer running time for ens is unexpected and I suspect it's just the CI variance, but then most of the other results don't tell us anything either because they're in a similar range.

Also, I'm not sure how OpenZeppelin in CI takes ~150 s to compile. The main difference is that it's being compiled with Hardhat rather than Foundry, but such a difference still seems odd. Is it downloading something rather than just building? Is the CI machine that slow?

github-actions[bot] commented 6 days ago

This pull request is stale because it has been open for 14 days with no activity. It will be closed in 7 days unless the stale label is removed.

ethereum / solidity

Reuse optimized IR for bytecode dependencies #15182