[webkit-dev] Build system update

[David Levin]

On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth <abarth at webkit.org> wrote:
>
> $ time git svn rebase
> [... update my working copy from changes during lunch (four revisions) ...]
> real    1m10.316s
> user    0m8.194s
> sys     0m16.400s
>
> $ time ./Tools/Scripts/generate-project-files
> real    0m4.339s
> user    0m3.888s
> sys     0m0.269s
>
> which is about 6.1% overhead on an almost trivial update.  We can also
> reduce this overhead to zero in many cases by detecting that we don't
> need to re-generate the project files if the inputs to the generation
> process haven't changed.
>
> It looks like you are using a slow mechanism for syncing. :)

TLDR version: 8% overhead for updating 191 revisions. *49% overhead for
trivial sync* (3 revisions) -- in addition to the added complexity (when I
sync or switch branches in git).

Here's my results for updating 191 revisions (81605 through 81796).

$ time git fetch && time git svn rebase

fetch, svn rebase times
real 0m21.071s, 0m36.195s
user 0m2.271s, 0m3.205s
sys 0m0.497s, 0m9.428s

total 57 seconds for a nontrivial update.

$ time ./Tools/Scripts/generate-project-files

real 0m4.642s
user 0m4.243s
sys 0m0.322s


An 8% overhead on a non-trivial sync.

For a trivial update of 3 revisions:
real 0m3.490s, 0m6.017s
user 0m0.932s, 0m2.266s
sys 0m0.184s, 0m2.824s

For a total of 9.5 seconds.


The generate project files step remained the same, so this adds a 49%
overhead for a trivial sync.

It also adds time (and complications) whenever I switch branches in git.

dave

PS For chromium, my experience is

$ time gclient runhooks --force
real 0m42.459s
user 0m29.236s
sys 0m2.543s

I don't know enough about chromium build system and gyp to know why it is an
order of magnitude slower, but this overhead is noticeable and annoying
there. I love the idea of a one project file system, but I have concerns
about project file generation on sync becoming the norm in WebKit. fwiw, I
checked how many gyp files were in chromium and it appeared within 20%.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110323/1039dc4a/attachment.html>