4 ms·
Main issue isn't that it break stuff but that it tend to be pretty slow to compile with it.
by yxhuvud 2y ago
Main issue isn't that it break stuff but that it tend to be pretty slow to compile with it.
- jorvi 2y ago.. 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.
- astrange 2y agoThis 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.
- Sharlin 2y agoWhich doesn't matter at all in a release build. And in a dev build it's rarely necessary.
- pcwalton 2y agoAt FAANG scale the cost is prohibitive. Hence the investment in ThinLTO.
- KerrAvon 2y agoAt FAANG scale, you absolutely want to have a pass before deployment that does this or you're leaving money on the table.
- scott_s 2y agoIt'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.