It's been this way for a while; the good news is that it should only
happen on initial build; subsequent builds don't regenerate the
bindings. If 3 minutes is really too much for a full build, we could
do your #2; hopefully the dependency checker would be smart enough not
to rebuild them if they were checked in. We'd have to find where to
check them in as well, because currently they are built into the
output directory (for both Release and Debug; perhaps we could just
generate one set, as I don't think they differ between release/debug
builds)
Mike
On Sun, Jan 4, 2009 at 11:08 AM, Brett Wilson <bre...@chromium.org> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
