> On Aug 29, 2017, at 9:10 AM, Chris Dumez <cdu...@apple.com> wrote: > > I worry about adopting unity build because while it makes clean builds > faster, it also slows down incremental builds. As a developer, I rarely do > clean builds, I mostly do incremental builds so this would likely make my > experience worse? > Unity builds also require a lot of code churn to resolve naming conflicts and > the resulting code does not look as nice.
My hope is that it won’t make your experience noticeably worse. I’ll keep doing experiments to ensure as little impact on incremental builds as possible. Unless, you modify just a single cpp file or many cpp files each in their own directory unified sources will still likely be a speedup. It’s likely that there are some files that we should exclude from unified sources as they take disproportionately longer to compile than the surrounding files (FTLLowerDFGToB3.cpp I’m looking at you!). The reality is that almost all the time spent (90%) compiling a .cpp file in JSC is parsing declarations, most of which are in headers. Since I would expect WebCore+ to have even more includes than JSC, the impact of unified sources on WebCore incremental builds is probably smaller than JSC. Also, keep in mind the 20% number was from compiling all ~46 Air .cpp files at the same time. Since we are only starting with 8 .cpp files per bundle 20% is probably an overestimate. As a side question, when you do incremental builds are the files changes generally all in one directory? Are the files usually headers or cpp files? > > Finally, the statement that the slow down of incremental build is acceptable > because we spend most of our time resolving dependencies seems to assume we > keep using make. Using Ninja would speed up incremental builds a lot by not > re-resolving dependencies so much. I think the solution to incremental builds, at least for Apple developers, is to make the CMake build the primary build system. That’s outside the scope of what I’m trying to do here but I think it’s also a worthy effort. > > -- > Chris Dumez > > > > >> On Aug 29, 2017, at 9:05 AM, Darin Adler <da...@apple.com >> <mailto:da...@apple.com>> wrote: >> >>> On Aug 28, 2017, at 8:34 PM, Ryosuke Niwa <rn...@webkit.org >>> <mailto:rn...@webkit.org>> wrote: >>> >>>> Wherever possible, we are going to want to convert file-static functions >>>> into private C++ class member functions. >>> >>> I don't think we should make this change. It would mean that whenever >>> the function signature changes, we'd have to modify the header file, >>> which in turn triggers rebuild of every cpp file which includes that >>> header file. >> >> >> That was my first thought as well. In fact, I typically ask people to do the >> opposite: Whenever a function does not require access to private members, >> convert from a member function that has to be in the header file to a >> function that is private to the source file. >> >> More recently I have started doing something different for the many >> functions that only have to be used on one place; I use lambdas to create >> nested functions. This has a couple nice properties: The lambda shares >> access to private members and anything else that the surrounding function >> has access to. We have the option of capturing rather than passing >> arguments, which can be clearer in some cases. It’s not quite as good as a >> separate function for visual separation; the lambda is often mashed together >> with the rest of the surrounding function. >> >> — Darin >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
