I've been working with some J2EE applications lately that can take 10 minutes to compile and deploy on my local machine. I added more memory. Nothing. I started tweaking things. Nothing. Finally I decided it was probably time to start breaking down the bottlenecks in the build.

Reading through the enthusiast sites, there's a notable lack of information about machines built for a particular purpose. For compiling and deploying applications, you need to look at the world a little differently than most of the review sites do.

General Notes

• Fast CPU cores matters, but not in the way that you'd think. Number of cores is not as important as speed of those cores. javac is singlethreaded. Always has been. It's only going to use one of those cores at a time. The more expensive dual CPU machines won't help you, and it's rare that you'll see even a 4 core machine maxed out.
• Memory bandwidth does help -- the more channels you have, the better as it reduces latency -- but from what I can tell, this only really becomes a large factor when it comes to virtualization.
• Huge amounts of memory don't help, but too little memory is likely to be fatal as it will lead to your machine swapping. 8 GB ought to be enough for anyone, but you will need a 64 bit OS to take advantage of it.
• Your single biggest bottleneck is I/O. You can see this if you turn on Performance Monitor and look at your disk queue length. If it's over 2 for extended periods of time, you have a problem.

 

Reducing I/O

• Buy an SSD with a Sandforce chipset. They have much faster write speeds than most SSDs, and have some neat tricks that may allow more use out of the system even without TRIM.
• Use AHCI to access your SSD drive. Make sure you tweak the BIOS to use SATA-3. Make sure you have the latest AHCI driver.
• Some of the SATA-3 drivers / controllers are wacky and give worse performance than SATA-2. You may want to experiment.
• Large J2EE deployments are are one of the few things that benefits from the data throughput that you can get from RAID 0. Do not put your SSD drive under RAID unless you are sure it supports TRIM (which it probably won't), or is a Sandforce. Do not use BIOS RAID. Windows 7 Professional RAID is going to be more portable and will work just as well, although you won't be able to boot from it. A RAID controller such as the LSI MegaRAID (make sure to get a SATA-3 capable one) will also work.
• EDIT: I've been told that if you have the memory, using a RAMDisk is a good way to speed up your deploy.  There are many RAMDisk drivers out there, but try DataRAM for starters.  I have not tried this myself.  Let me know how it goes.

Parallel Builds

If you're using Ant, a cheap and easy way to score some wins is to make sure that ant has the <parallel> task wrapped around any IO tasks that you need to do at the same time. Note that Maven is also single threaded, so you're not going to see any benefits there. (EDIT: although Maven 3 has parallel builds as an experimental feature.)

A better way to parallelize a build is to split your code into modules, and then build several modules in parallel once they have no common dependencies.

Multi processor boxes may hold their appeal, but single processors are so much cheaper than multi-core enabled boxes that it's not worth it. Yes, you could set up a server class machine with virtualization, but if you have the money and the need to buy a server class setup, you are probably in a situation where you will need to buy several machines shortly. The enterprise way to do this is to do distributed builds using Hudson. Read about it here.

TL;DR version:

Using the Techreport Guide as a model:

• AMD Phenom II X4 970 Black Edition (although technically the Core i5-680 is the fastest single core CPU you can buy)
• LSI SATA/SAS 9261-8i RAID card (or Windows 7 Professional, which is much cheaper)
• 2x Corsair Force CSSD-F120GB2, using RAID 0 (see here)
• 8GB RAM DDR3-1333
• 430W Power Supply (you won't need more)
• ASUS M4A89GTD PRO
• Windows 7 Home Premium 64 bit (or Windows Professional if you want software RAID)

Put this together, and you will rarely have to wait for your builds or tests to finish. Using the techniques above, I knocked down the 10 minute build down to 1 minute, 42 seconds.

Let's restate that. The single biggest thing slowing me down as a developer is the amount of time I spend waiting for the computer to do its thing. 10 minutes delay between making a change and seeing that change running is a long time to hold a program down: longer if you have to wait for the integration tests to finish as well. So when I chopped that cycle time down to 1 minute, 42 seconds -- that changed my experience from "time to get a coffee" to "time to write another selenium test." Whatever money you think you're saving by cheaping out on computer parts, spending the cash to reduce your cycle time by 90% is worth it. Even if you're on a Macbook Pro, you can get some ridiculous gains by simply swapping out your mechanical hard drive for an SSD. Trust me on this: it is worth it.

Good luck, and let me know what you pick.