Faster, but not quite there yet…

So as others have been posting about, we’ve been making some headway on our progress on the GoFaster project. Unfortunately it seems like we’re still some distance away from reaching our magic number of a 2 hour turnaround for each revision pushed.

It’s a bit hard to see the exact number on the graph (someone should fix that), but we seem to teetering around an average of 3 hours at this point. Looking at our build charts, it seems like the critical path has shifted in many cases from Windows to MacOS X. Is there something we can do to close the gap there? Or is there a more general fix which would lead to substantial savings? If you have any thoughts, or would like to help out, we’re scheduled to have a short meeting tomorrow.

Anyone is welcome to join, but note that we’re practical, results-oriented people. Crazy ideas are fun, but we’re most interested in proposals that have measurable data behind them and can be implemented in reasonable amounts of time. :)

2 thoughts on “Faster, but not quite there yet…”

  1. Not sure if I’ll be able to make it to the meeting, but here is a thought: The main reason why OSX builds are slower is that in practice, we’re doing two builds. I see two possible hacks around this, one of which I’m not certain of the impact:
    - Build universal binaries in one pass. Apple’s gcc allows to build both i386 and x86-64 binaries with one command line. I don’t know if that’s actually faster than doing one pass in i386 and another one in x86-64
    - Build i386 and x86-64 binaries separately, in parallel, on different machines, and aggregate the result in a universal package when they are both finished.

  2. Cool. We actually talked about this during meeting, and came to the conclusion that doing unified builds in a single pass was the way to go. Ted Mielczarek is going to look into finding someone to do this.

Comments are closed.