Go 1.22 Inlining Overhaul

It's a tough problem, because the situations in which fast build times matter are mostly during local development and test. Only at really insane scales do they become a problem for production releasing and CI/automated testing. An environment variable that can be set on a dev workstation globally (and overridden with CLI flags) would probably be sufficient for opt-in

bjoli2• 3 years ago

I don't know if you have ever written an inliner, but it seems simple enough until you realise you are trying to restrain a rabid dog on a leash.

I wrote one a long time ago that was a part of a project that was moderately popular, but it had issues and incremental changes had a tendency to trigger weird edge cases. in the end someone with a CS PhD wrote a different one (while keeping quiet on the awfulness of my implementation) and it was so much nicer in every way. Reading his code was like reading poetry.

That was when I realised code should be deliberate. Every line is a step towards a goal. I think that is why rewriting something when you understand the problem domain better can be so liberating.

pjmlp3• 3 years ago

A good example on C and C++ code, is the UB that isn't there in first place, but gets triggered due to the way code is inlined, and suddenly the optimizer becomes aware of optimization opportunities that wouldn't be taken, if it wasn't for the code being inlined.

kevincox• 3 years ago

I'm not sure that I understand. A compiler inlining a function can't create undefined behaviour (UB) where there wasn't any before. Otherwise it would be breaking valid code.

Do you mean that after inlining the compiler has more visibility can can idenitfy UB that it was not sure was UB before?

deagle50• 3 years ago

What would have been bad about letting us annotate hot functions? My binary size is my problem.

Go 1.22 Inlining Overhaul

Related Stories