[diego]

I interviewed at Netscape shortly after they announced they would release the browser as open source (June '98, ended up going to Inktomi). I remember being very excited about this, and downloading the source when it first became available. I found out that my (decent) desktop machine was not powerful enough to compile it. When I found a machine that could compile it, it took about 8 hours.

No surprise that it remained a Netscape project for so long.

[daimyoyo]

"When I found a machine that could compile it, it took about 8 hours."

Thank you. It never occurred to me that you need a lot more processing power to compile code than you do to run the software you're creating. You just saved me a lot of heartache in a few months once it's time to start compiling. I love HN.

/srsly

[Simucal]

This isn't always the case. It is highly dependent on the language, the compiler used, the size of the code-base and many other factors.

Most of the small to medium sized project I have worked on compile in what seems like an instant.

However, I work on a medium-to-large code-base at work and it takes around 8 minutes to compile on our build server and around 12-15 minutes on my dev machine. Even these speeds seem tremendously slow to me. I can't imagine being a developer on a huge C++ project and having to wait tremendously long build times. When your compile times aren't near instant it really changes how you program. That feed back loop of code-compile-run-repeat becomes more like code-double check code-code some more-compile-surf the web-run-repeat.

[rayval]

Ideally, you should not be in this situation where you have to compile large amounts of code to go through the code-test-debug cycle.

Even in a large project, there should be subysystems that a developer owns and works on that can be partitioned or isolated from the rest, and execute within a test harness on a dev machine -- a harness that feeds the subsystem inputs and records outputs.

Successful projects either begin with or evolve to a state where they have the architecture, the toolset, the process and the culture to allow devs to enjoy a fast code/debug cycle.

[Andrew-Dufresne]

Besides subsystems, tools like make and nmake utility can also reduce the compile time.

Make figures out automatically which files it needs to update, based on which source files have changed. It also automatically determines the proper order for updating files, in case one non-source file depends on another non-source file. As a result, if you change a few source files and then run Make, it does not need to recompile all of your program. It updates only those non-source files that depend directly or indirectly on the source files that you changed.

[voxcogitatio]

Yes, but large projects often need to use recursive makefiles, which are notoriously flaky at detecting what has changed (if anything).

[drothlis]

No project needs to use recursive make.

"Recursive make considered harmful": http://miller.emu.id.au/pmiller/books/rmch/

[alnayyir]

ccache. Come on guys, this is basic tooling.

[bzbarsky]

ccache only helps so much. On a pretty modern fast machine, typical web browser source takes 5-10 minutes to compile for me even with ccache (depending on what I changed).

Of that, 30-90 seconds is just linking (and no, gold doesn't help all that much).

[gaius]

It never occurred to me that you need a lot more processing power to compile code than you do to run the software you're creating

It never occurred to you because it isn't true! You could for example write a trivial raytracer that compiles in seconds and takes hours to render a scene.

[windsurfer]

...Could you explain? I don't understand what you're saying.

[rmc]

Also remember that compiling code can use memory. I once had a compilation causing the machine to swap. That took a while to compile.

[sambeau]

This is often the case. My last company had software that took 45 mins to compile on high-end machines in 2010.