SSD and programming

Question

I'm trying to put together a business case for getting every developer in our company an Intel SSD drive.

The main codebase contains roughly 400,000 lines of code. My theory is that since the code is scattered about in maybe 1500 files, an SSD drive would be substantially faster for compiles. The logic being that many small reads really punishes the seak-time bottle-neck of a traditional hard-drive.

Am I right? Is SSD worth the money in productivity gains by reducing the edit/compile cycle time?

Answer 1

If your development bottleneck is that of I/O seek time during compiles, you're definitely doing software engineering wrong.

---

To elaborate:

Most programming involves a lot of work other than actual compiles:

• Requirements analysis
• Designing the solution
• Coordinating with other team members to understand the interfaces of their components
• Typing in the code
• Designing and coding test suites
• Running test suites and analyzing results
• Committing code to source code repository
• Documenting work
• Reading and writing bug logs
• Meetings, emails, and IM

Suppose the time you spend waiting for a compile is actually only 2% of each developer's day (even that is an overestimate). If you can increase the throughput of your compiles and cut compile time in half, now compiles are 1% of each developer's day instead of 2%. Not a huge change, and perhaps not the best use of $1000 per developer.

One way to look at it is how long it takes to pay off. Assuming a $100K salary, a $1K SSD drive that increases developer productivity by 1% pays off in a year. But the developer would have to be writing code like they were working in a sweat-shop, every day, for a year.

Instead, if you can invest the $1K per developer into some training to make one of the other work tasks I listed above more productive, you might get much better bang for the buck.

Or else use that money to hire someone to offload some work from the development team (e.g. QA Tester, Support Analyst, Sales Engineer, IT Technician, Project Manager, or Office Assistant).

Another suggestion: studies show that if you improve the workers' environment, it results in a 10% productivity improvement. It can be an expensive improvement, or something as simple as some wall art and houseplants. It doesn't matter -- it tends to result in +10% productivity improvement even for a modest improvement to the environment.

I suggest getting the office carpets shampooed, and clean up some of the accumulation of empty boxes and junk.

Answer 2

My boss tells me that back in the day (developing on Windows 3.0) he got a huge speed increase from putting precompiled headers (and possibly object files) onto a RAM disk, instead of being on a slow hard disk at the time. I haven't seen any programming-related benchmarks for SSDs or otherwise, but I'd be very interested in them.

Here are some benchmarks for SSDs in normal operations:

http://techreport.com/articles.x/16291/6

Which of these would correspond most to compiling stuff?

Answer 3

How much time does it take right now? Buy one to see how you'd gain by this, check the time against the price of all these still-very-expensive SSD and see whether it is worth it or no.

The main business case for SSD is generally that they have no moving parts and are exactly what you need for a laptop... You can have a better bandwidth by having several drives instead of just a single one.

Any someone else said, if the bottleneck is compile time, you have a bigger problem than just I/O time for compiles.

Answer 4

Absolutely, but your productivity gains are going to depend on the particular drive you buy. I would benchmark your compile process on at least these two drives:

Intel X25-M

OCZ Apex

And don't exclude speedups to other aspects of work such as launching programs and exploring folders from the equation. If you can create a video or live demo of work using a new drive that demonstrates how much faster things go, that should be effective.

Answer 5

There's not enough information to answer the question. In particular:

• How long does a normal (incremental) rebuild take?
• How long does a full build take?
• How many times a day does a developer do each of those?

Once you know that, you can measure (or guess) the difference in time per day an SSD-based build will take and thus the savings they'll represent.

If the build environment is well engineered, then the incremental build should be super-quick irrespective of the total number of files in the project. If that's not the case, then it's likely to have a bigger win than faster hardware.

Answer 6

@Bill Karwin

Thanks for your elaboration. In a way, the problem is not the compile time itself, it is the fact that a long compile time leads to distraction which breaks your "flow."

If a compile takes longer than a minute, then you start to read your e-mail, browser Reddit, read Slashdot, write another paragraph in the specification you need to finish for Monday.

Three minutes later (the compile actually took a minute and thirty seconds, but because you got distracted the time until you actually notice this is much later) you realise the compile is done.

Now your flow is broken and there is a visible mental cost of getting back in to the flow.

That is the incidental productivity problem I'm trying to solve.

Answer 7

If you get 40 second builds from a RAM-disk (compared to 2-3 minutes on a HDD), then why don't you simply give all the developers an additional 2 Gigs of RAM and change your build (or even development) system to use a RAM-disk?

It's tons cheaper (at the moment) and RAM can be used for a lot of other tasks as well.

Answer 8

I feel that SSDs are currently too expensive to be worthwhile, and are particularly poorly suited for dev machines.

Reason #1: the write speeds on lower priced models are generally significantly slower than a traditional hard disk. This problem is especially amplified when it comes to very small files, which is exactly the thing you are dealing with when compiling. The reason for this is that a SSD must rewrite an entire block.

Reason #2: SSDs have a very limited amount of writes when compared to regular hard disks. They feature write-leveling algorithms but the lifetime in general will be much lower than a regular disk.

Reason #3: build tasks are generally limited by write operations, NOT by read operations

So to recap, if you are going to go SSD, make sure your company is doing research and buying good ones. There are a lot of garbage SSDs that have marginal read speed increases, and are actually much slower than regular disks when it comes to writing. The only thing you can be sure of is faster access time.

Answer 9

for long compiles, first try ccache. it might give you more of a speedup than throwing hardware at the problem.

Answer 10

Joel Spolsky says it's "totally worth it" - http://www.joelonsoftware.com/items/2009/03/27.html

Joel didn't have much luck with compile times, but if you know (by evidence) that disk i/o is the bottle neck in your compile times, then a SSD should help.

Most engineers underestimate the cost of human (programmer) context-switching. Compile times under a minute greatly reduce human context-switching, and are worth the slightly higher hardware cost. Hardware is dirt cheap. People aren't.

Answer 11

If you are doing this on a desktop, you might consider getting a battery-backed RAM RAID controller with gobs of RAM. That'll improve your read/write times tremendously, while still preventing loss of data.

Answer 12

We have been doing some SSD testing on compile times for our monstrous code base. Previously a complete debug build from the commandline would take approx one hour. We started using two SSDs with RAID 0.

After changing to the new drives there was pretty much no change to compile times, which was a disappointment. One vast improvement was the speed of completing general tasks (i.e. launching apps, large file copies etc).

If your budget will stretch I would recommend SSDs for developer machines. They wont make much difference to compile times, but they will make vast improvements elsewhere which will reduce time wasted on non-development tasks.

Answer 13

Based on compile times there probably isn't a business case for it. For VS 2008 and C# at least, we've found that if you have a fast disk then an SSD will probably help very little, if at all. A faster CPU will make a big difference though.

I have provided data to back this up in my anser to the related question on Stack Overflow: SSD drives and visual studio IDE. Big improvements ? Real usage stories, no theory.

That said, an SSD will make VS load much faster and just generally make the PC 'snappier'. It just won't meaningfully improve compile times, especially not like a faster CPU will.

Answer 14

I've got a new answer/reason to bring to the table, I know this is an old question...

Do it for your office safety!

SSDs reduce the amount of office sword fights, by reducing the time spent compiling. That alone might not be a compelling business case, though.

In seriousness, as others have already stated: buy one and find out the numbers for your situation. Weigh how good of an investment they are to buy for all developers. Intel are drives the safest best still, but there are multiple good options at this point if you read some Anandtech reviews.

In my experience, SSDs help other aspects of a development work flow even more than compile time, although it is a notable benefit by itself (YMMV - some compile tasks are more CPU bound). In our case (Java) and lots of files, it did give a nice boost.

Here are the big wins for us:

• Subversion performance
• IDE performance (Eclipse in our case)

In our case, we have a large subversion repository and a lot of files (45k files in a workspace), so anything from opening up a TortoiseSVN commit window, to the actual commit time, to merging branches is SIGNIFICANTLY faster. YMMV, but anything that benefits from the SSD's fast random reads/writes will generally be noticeably faster, in some cases by an order of magnitude (svn usage in our case, on the client side).

Just my 2 cents from my own experience using the Intel x25-m SSDs - everything is snappier, and they are totally worth it. SSD prices have dropped substantially this year... and unless you have a truly monster CPU ($1k spent on the CPU alone) it is likely the best overall performance improvement for your system.

Yes, "it depends" by how much, but SSDs rock. Certain prominent developers agree.