Re: [GD-General] Compile times
Brought to you by:
vexxed72
From: brian h. <bri...@py...> - 2002-12-10 05:38:16
|
> 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) Then we have very similar build times and sizes for our respective "small" projects. So the question is -- what are the really big chunks that "big" project adds that hoses everything? STL is the obvious commonality, because large projects sans STL still seem like they compile pretty quickly. > 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). So it would seem that STL is directly the culprit for lots of these build time explosions. > Unfortunately the link time didn't seem to drop any, which is the Are your codebases built into a single monolithic EXE, or an EXE and multiple DLLs? The latter approach seems to help link times appreciably. > nobody under the age of 30 can be bothered to type "make" :). Kids these days. =) Speaking of which, I'm curious if anyone has tried using jam (Just Another Make)? make isn't even quite 80s technology, much less 2000+ technology. It's mind bogglingly obtuse, yet somehow manages to survive even today. jam is an attempt to sort out this mess somewhat more cleanly, and Apple has migrated to it for ProjectBuilder. Brian |