"But if you're compiling huge C++ (or even Java) projects then you probably want good I/O (possibly an SSD, preferably in RAID1 config for redundancy), lots of RAM and a good CPU."
For huge builds it makes sense to go with a compile farm. Working on a god box that sits idle 99% of the time is a bit wasteful.
Quick aside: does ESXi still impose too much overhead to move a compile farm onto VMs?
A friend of mine tested it 3 years ago and it was something like 300% slower (no idea about the disk config, but he's a smart guy). It would have been worth it at anything under about a %50 hit...
We tested it at my last job maybe 5 months ago and it was a complete failure. Granted we didn't spend a lot of cycles on it, but we saw how slow it was and went back to native hardware pretty quick.
Two reasons:
- Easy migration between hardware configurations of a running system.
- Snapshots to revert quicker after a failed upgrade / change. (Typically in addition to traditional backups.)
For local compiles with good I/O I use RAM drives, hosting most of the project, the IDE and the compiler/jvm on RAM drives. The files are backed up on a git repository on the hard drive, so I don't have to worry about data loss if the RAM drive has problems.
If you have to use a laptop, throw away the useless DVD drive and change it with a second HDD/SSD.
Many of the better laptops can also have a second mini-PCIE slot for an internal 3G modem. Install a modem there. This will help you a lot: 1) Internet access everywhere, 2) you don't have to worry about signal (the internal antenna is bigger and better) 3) you don't have to worry about crappy USB modems and their crappy drivers.
For huge builds it makes sense to go with a compile farm. Working on a god box that sits idle 99% of the time is a bit wasteful.