On 4 September 2015 at 17:11, Tom Tromey <t...@tromey.com> wrote: > Manuel> The overall goal of the project is worthwhile, however, it is unclear > Manuel> whether the approach envisioned in the wiki page will lead to the > Manuel> desired benefits. See http://tromey.com/blog/?p=420 which is the last > Manuel> status report that I am aware of. > > Yeah. I stopped working on that project when my manager at the time > asked me to work on gdb instead. > > I think the goal of that project is still relevant, in that C++ > compilation is still just too darn slow. Projects today (e.g., firefox) > still do the "include the .cc files" trick to get a compilation > performance boost.
But we don't even know why it is so slow, no? (Or perhaps it is known:https://gcc.gnu.org/wiki/Speedup_areas#C.2B-.2B-_improvements but no one has decided to fix them) Clang++ is much faster yet it is doing more and tracking more data than cc1plus. Thus, there have to be things that can be optimized in the C++ parser. For example, we know that by-passing the textual assembler representation has to speed-up compilation (https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00188.html), specially for large programs (simply printing it more efficiently already leads to measurable speed-ups: https://gcc.gnu.org/ml/gcc/2011-06/msg00156.html). > On the other hand, I'm not sure the incremental compiler is the way to > go. It is a complicated approach. Perhaps libcc1 could be re-purposed for this? It allows inserting code into an already existing binary. Perhaps it could allow replacing code from it? I have only a nebulous idea of how libcc1 works, maybe this does not make any sense. > Perhaps better would be to tackle things head on; that is, push harder > for modules in C and C++ and fix the problem at its root. Probably yes. Unfortunately, I don't know of any plans to implement this in any form (much less for C). Cheers, Manuel.
