For the macOS and iOS ports, we have the additional problem of overhead from the build system. Our make+xcodebuild based system takes a surprisingly long time even for a no-op build, or for a small incremental "just changed this one implementation file" build.
There's also some indication that newer versions of clang may have gotten slower at compiling the same code, perhaps due to more aggressive optimizations. - Maciej > On Apr 24, 2017, at 11:10 AM, Alex Christensen <[email protected]> wrote: > > Thanks for the data, Carlos! This is a growing problem that is hurting > productivity. We’ve discussed it a bit and haven’t done enough about it. > Here are some of the ideas I’ve heard: > > 1) Reduce #includes by doing more forward declaring and less inlining. We > would probably need link time optimization to not lose performance benefits > of inlining functions in headers. > 2) Use distributed build tools and caches to cover up the problem. WebKit > would still be prohibitively hard to compile for people without lots of > expensive computers, but we could greatly improve the productivity of large > teams. > 3) Use C++ modules > 4) Put more commonly included headers into precompiled headers > 5) I remember somebody claiming a few years ago that replacing #include > “Something.h” with #include “path/to/Something.h” reduced compile times > because it required fewer include paths, but I don’t think anybody has > measured the improvement recently. > 6) Optimize the compilers we use > > We should look into all of these and more. Compiling WebKit also uses a lot > of memory, and our binary size continues to increase. > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
