I worry a bit that we are adding so much passes to the pipeline (removing 4, adding 9, partly conditional) that optimization will become slower and slower while we keep doing this. I see that the additions reduce fixtures by about 330 lines, which is good in classical terms, and I'd lean towards merging, yet the relativistic concern remains that achieving the speed of light (zero lines of output) can only be achieved by supplying infinite energy (running passes forever) and is ultimately impossible because of diminishing returns unless becoming massless (optimizing no code at all).

Or: Where do we draw the line? How much slowdown are we willing to accept for what gain? And how can we measure this as a function of time taken vs code optimized?

Basically this attempts also speedup pipeline by doing some work earlier, before SSA and flattering. In my internal tests it's really little bit faster than previous scheme.

Where do we draw the line? How much slowdown are we willing to accept for what gain? And how can we measure this as a function of time taken vs code optimized?

It will be great have some compiler benchmark with aggregate perf metrics and ideally with CI integration

For npm run test:compiler -- --create (and via ts-node) roughly comparison:
master: Time 80896 ms
this pr: Time 77528 ms

Since this touches a lot of fixtures, can you merge master into this PR and regenerate the fixtures? Mostly just in case, i.e. if an export not present before #1422 would now be present and somehow introduce a fixture-only conflict.

Sure, done! But it seems it hasn't any changes

Thanks!

🎉 This PR is included in version 0.14.8 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀