On Tue, Jun 8, 2010 at 3:21 PM, Peter Kasting <pkast...@google.com> wrote: > > On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel <e...@webkit.org> wrote: >> >> Has anyone spent any time trying to reduce the number of includes in >> WebCore? I know we have: >> https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes >> >> But I feel like we still have way too many unnecessary includes. I >> failed to find any tools for reducing build times or includes with my >> brief Google searching. But perhaps others have looked into this >> problem for WebKit or other projects? > > I know someone once suggested that the build would be sped up if the > #includes had longer paths (something like what happens in the Chromium tree) > so that the toolchain didn't have to spend as much time scanning the (large) > number of different directories on the #include path list. However, I don't > know how true this is, and plus, converting all the files to use this method > would be a huge change (presumably done via a script). I imagine removing > unnecessary #includes, as you suggest above, would provide a much bigger > benefit.
In a previous job, I spent a lot of time optimizing build times and reducing the number of include directories scanned made an enormous difference. However, that was C, not C++, and so the compilation and link steps were much faster than the preprocessing step (compared to C++, at least). I would still expect the file system scanning to be much slower than the actual preprocessing, so fixing include paths would probably still make a bigger difference than reducing unnecessary includes, but I'm not sure how much difference either contributes to the overall numbers. -- Dirk _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
