On Apr 16, 2012, at 6:43 AM, Richard Guenther wrote: > Well, the number one advantage of replacing PCH is that it would kill > the current PCH implementation which is tied to our garbage collector...
If compile speed isn't important to people, there is little reason to keep pch around. Once that decision is made, the rest is easy. For translation units that take 1 second to compile, the difference between 2s and 9s is 4.5x, though, with link time, the actual benefit drops significantly. I'd argue that the benefit of pch is worth the cost. As for bugs, pch was designed to be high quality, low maintenance, I think it achieves that goal. I've seen the effort required for pph and the number and types of bugs fixed, and my impression is that pch is but a pale shadow, compared to it. So, easier to implement, faster, fewer bugs, seems good to me. I do wish we have a more powerful language in which to express pch, so that the way pch impacts the compiler is reduced. As we move to C++, there might be an opportunity to re-craft how that interface is done, so as to eliminate even more of the cost of pch in the compiler. The cheaper the implementation is, I think the easier it is to retain pch. Ultimately, the best way to remove it, may be to craft a language level solution for the C family of languages, in which the cost of headers is engineered to be 0, or at least, very close to it. I'd encourage that solution, as then, we can rip out both pch and pph, which I think would be a good direction to move in. Now, long term, it is possible that with more cores than translation units, a full rebuild, no pph or pch of any type, would be the fastest and simplest implementation. We're not there yet, and I don't know if the lines of the two will cross... but many they will. Maybe power efficiency will matter even in that case, so maybe pch will still be useful.
