I have been doing some build profiling over the weekend. When I run
IncrediBuild, computing dependencies takes about 30 seconds. Then one
CPU starts "performing custom build step" which is
V8Bindings_prebuild. In parallel, most dependencies like ICU compile
in the next minute.
Then it hangs for 3 minutes waiting for V8Bindings_prebuild.
Then it compiles all of WebCore and some remaining parts of Chrome in
the next 4 minutes, and links in 2 minutes.
Why is 1/3 of my time wasted waiting for a makefile to run? During
this time I see a continuous stream of sh.exe, perl.exe, and
cc1plus.exe getting spawned and killed. Looking at the makefile, this
happens >300 times, and each time perl has to search a bunch of
different directories of WebCore sources to find the file in question.
If I already have this step completed, IncrediBuild can compile all of
chrome_exe from scratch in 5:50 on my computer, which is really fast!
With a clean debug directory, it takes 8:57. It seems like this is a
really big waste of everybody's time. I don't entirely know what's
going on, and I barely know Perl, but it seems like there are two
options:
1) Improve the step to list the exact locations of each file, and to
only run perl once, iterating over the list in perl rather than in the
makefile. This loses the incremental aspect if you do change anything,
but most people aren't changing the IDL files. I bet this would make
it orders of magnitude faster.
2) Check in prebuilt V8 bindings. This means that the WebKit merger
would need to run an extra step, but everything would magically work
for everbody else. I really like this solution because I think the V8
bindings are the most common thing that causes weird build errors when
you sync after a new WebKit has been pulled, and I think it's also the
main reason that you have to physically delete the output directory
instead of doing a regular clean. It could be that having the correct
versions checked in saves everybody a lot of rebuilding in addition to
saving several minutes on each build.
I really like option #2. Does anybody have any thoughts on how well
this would work?
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
