Hacker News Reader

Comment by pingyong | Hacker News Reader

While I vastly prefer this workflow wise, for large projects it can increase compile time drastically. https://lwn.net/Articles/744507/

For projects that will never have more than ~1 million LOC it's probably fine. Less than ~100K, definitely preferable.

View on HN

What about ThinLTO? The idea of having a overnight full build that creates some kind of cache which incremental builds throughout the day can use to do fast whole-binary LTO seems like the best of both worlds.

Basically just wondering if anyone has first hand experience using this kind of thing on a large project.

ThinLTO was written by people responsible for peak optimization of very large programs at Google. I honestly can’t call it “fast” but it’s a lot faster than GCC LTO. You normally only peak-optimize your release builds so it’s not like developers are sitting there counting the seconds.

> You normally only peak-optimize your release builds so it’s not like developers are sitting there counting the seconds.

Sometimes you do want to debug a release build because the optimizations have gone wrong, though. In that case, it's helpful if release builds build quickly, and especially if they rebuild quickly as you turn various sub-optimization flags on and off.

Yes, and sometimes you want to validate a performance change and you need the release build to run in the benchmark fixture, and then it's irritating that the build takes forever but what can be done? ThinLTO's real benefit is that it uses so much less memory than legacy LTO and can be applied to larger programs (like Chrome).

Those large projects benefit the most from LTO as well though.

Reply on news.ycombinator.com