Hacker News Reader

Main issue isn't that it break stuff but that it tend to be pretty slow to compile with it.

.. that's why you compile without LTO during development and do a final 'compile with LTO > profile > fix / optimize > compile with LTO' pass.

Compilation happens once and then runs on hundreds of thousands up to billions of devices. Respect your users.

This assumes that LTO is strictly better than no-LTO, ie only gets faster, has the same optimization hotspots, and doesn't break anything.

I would recommend only doing things that fit within the 'build > text > fix' loop.

Which doesn't matter at all in a release build. And in a dev build it's rarely necessary.

At FAANG scale the cost is prohibitive. Hence the investment in ThinLTO.

At FAANG scale, you absolutely want to have a pass before deployment that does this or you're leaving money on the table.

It's not as obvious a win as you may think. Keep in mind that for every binary that gets deployed and executed, it will be compiled many more times before and after for testing. For some binaries, this number could easily reach the hundreds of thousands of times. Why? In a monorepo, a lot of changes come in every day, and testing those changes involves traversing a reachability graph of potentially affected code and running their tests.

Reply on news.ycombinator.com