[webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Maciej Stachowiak]

> On Aug 29, 2017, at 9:10 AM, Chris Dumez <cdumez at 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 <darin at apple.com <mailto:darin at apple.com>> wrote:
>> 
>>> On Aug 28, 2017, at 8:34 PM, Ryosuke Niwa <rniwa at webkit.org <mailto:rniwa at 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 at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170829/55b3e7e1/attachment.html>