[Arelius]

Yeah, if you're development process requires LTO you may be holding it wrong....

Specifically, if LTO is so important that you need to be using it during development, you likely have a very exceptional case, or you have some big architectural issues that are causing much larger performance regressions then they should be.

[IshKebab]

> you're development process requires LTO you may be holding it wrong....

Not necessarily. LTO does a very good job of dead code elimination which is sometimes necessary to fit code in microcontroller memory.

[jcalvinowens]

If you're debugging, and your bug only reproduces with LTO enabled, you don't have much of a choice...

[paulddraper]

Sure, for that 1% of the time.

[thesz]

...which takes these remaining 99% of a development time...

[saagarjha]

Surely your LTO bugs are not so easy to fix that they take less time to resolve than linking itself does.

[benatkin]

Being able to choose a middle ground between development/debug builds and production builds is becoming increasingly important. This is especially true when developing in the browser, when often something appears to be slow in development mode but is fine in production mode.

WebAssembly and lightweight MicroVMs are enabling FaaS with real time code generation but the build toolchain makes it less appealing, when you don't want it to take half a minute to build or to be slow.

[josephg]

> Yeah, if you're development process requires LTO you may be holding it wrong....

I spent a few months doing performance optimisation work. We wanted to see how much performance we could wring out of an algorithm & associated data structures. Each day I’d try and brainstorm new optimisations, implement them, and then A/B test the change to see how it actually affected performance. To get reliable tests, all benchmarks were run in release mode (with all optimisations - including LTO - turned on).