> On 30 Aug 2017, at 8:16 am, Geoffrey Garen <gga...@apple.com> wrote: > > Interesting. > > The majority cases here are 7 or fewer files. I don’t see much difference > between these cases and our existing benchmark for one file, where Keith > described the build time delta as "barely noticeable".
Was this a .cpp file or a .h file? I assume that under a unified system, changing a single .cpp file means more total code compiled but the same number of files. Changing a single .h file would hopefully mean fewer files compiled, but potentially a lot more total code. Does the "you'll hardly notice the difference" rule apply in both cases? Dan, how did you gather the data below (i.e. how did you count the number of files compiled)? Dean > > For the minority cases that are 23 - 75 files, these challenge Keith’s > description that "most of the build time in incremental builds is scanning > dependencies” — assuming that you get unlucky enough for none of the files to > bundle together. > > If possible, it would be helpful to know if these files were in the same > folders or not. > > Alternatively, we can approximate the answer by benchmarking svn up for > individual revisions. > > Geoff > >> On Aug 29, 2017, at 2:21 PM, Dan Bernstein <m...@apple.com >> <mailto:m...@apple.com>> wrote: >> >> >> >>> On Aug 29, 2017, at 1:39 PM, Geoffrey Garen <gga...@apple.com >>> <mailto:gga...@apple.com>> wrote: >>> >>>> I see. The right question to ask would have been how much change occurs in >>>> their working copy between consecutive incremental builds. >>> >>> If you want to help make our benchmark righter, please do share any data >>> you have about the average content of an incremental build that is distinct >>> from a daily svn up. >> >> Here is the data from three WebKit contributors surveyed today. For each >> contributor, each line corresponds to a single consecutive incremental build >> they’ve performed today, and the number shown is the number of files that >> were compiled in that build: >> >> A >> B >> C >> 41 >> 4 >> 1 >> 2 >> 1 >> 1 >> >> 1 >> 1 >> >> 4 >> 7 >> >> 4 >> 58 >> >> 5 >> 27 >> >> 3 >> 23 >> >> 4 >> 61 >> >> 5 >> 3 >> >> 7 >> 75 >> >> 1 >> 2 >> >> 6 >> 1 >> >> 4 >> 2 >> >> 4 >> 1 >> >> 4 >> 47 >> >> 5 >> >> >> 3 >> >> >> I hope this helps. It certainly gives me an idea of what a righter benchmark >> would be. > > _______________________________________________ > 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
