> 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.
Given the stats presented, if you're rebuilding at least two files in the same slice, you get a speedup. For rebuilding only exactly a single file, you get a small slowdown. Your worst case is rebuilding many files but all from a separate slice. Not sure how likely this is. For Apple folks, the penalty would be more than reversed by switching to CMake+Ninja as the main building system for engineering builds (which I think is the plan?) - Maciej > > 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. > > -- > 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
