Re: [GD-General] Compile times

[Thatcher U. <tu...@tu...>]

On Dec 09, 2002 at 02:17 -0800, Brian Hook wrote:
> 
> I can't help but wonder if your slow rebuilds on Linux and OS X are the
> result of using gcc and STL?  Because that factor of 9 is just mind
> bogglingly dramatically different, enough so that it would raise alarm
> bells.  gcc has issues, but damn, not THAT many issues.

In addition to being slower than VC in general, gcc is surpisingly
slow at compiling STL code, in my limited experience.  A factor of 9
sounds awfully high to me too, though.

At one point I got curious and measure the code pulled in by "#include
<vector>" using various STL's -- VC6's default STL pulls in 122KB, gcc
pulls in 181KB, and STLport-4.5 pulls in 203KB.

I suffered severe compile-time shock when I first started working at
Oddworld, so I remember timing a build of Soul Ride (my immediate
prior project) on the machine at work.  Stats:

full build: ~45 seconds (VC6)
1.80M total
1.46M .cpp  (94 files)
0.15M .c    (19 files)
0.18M .h    (88 files)
(71K lines total)

About 0.16M of the .cpp was written by a contractor who used STL; the
rest was written by me with little to no STL.  The .c is Lua 3.2.

The Oddworld code base at that time was about 200K+ lines (dunno how
many megs) and used STL.  I think I measured a full build at like 12
minutes (VC7), but my memory could be wrong.

Our new codebase is relatively cleaner than before IMO, but still uses
STL.  A full game-only build still takes ~12 minutes (VC7) on my
(relatively slow 1GHz) laptop.  (This particular laptop is much slower
at compiling than the machine used for the above timings.)

Here are the size stats:

5.83M total
4.33M .cpp  (538 files)
1.50M .h    (568 files)

The last time compile times came up, someone on this list mentioned
doing "lumped" builds, where you use a script to #include a whole
bunch of .cpp files into one big compilation unit.  I cooked up some
make/perl monstrosity to try that out with Oddworld's code, and got
some stunning results: 3 minute full builds!

The reason this works is because the compiler only reads headers (and
builds data structures from them) once for the whole lump.  As opposed
to reading, building structures, compiling a few hundred lines, and
then flushing everything out again, once for each source file.  Our
typical #include line-count is in excess of 25K lines (because of
STL).

Unfortunately the link time didn't seem to drop any, which is the
biggest determinant of our usual compile cycle time (and the build
process changes were deemed too wacky to be adopted, since it seems
nobody under the age of 30 can be bothered to type "make" :).

-- 
Thatcher Ulrich
http://tulrich.com