Crucial's MX100 solid-state drive reviewed
techreport.com
techreport.com
If anyone reading this uses a laptop for development and it has a hard disk, please upgrade. The cost in time and frustration makes it worthwhile purely for economic reasons.
Now, it can be said that the need for good wear leveling and latency hiding is what causes the controllers and their firmware to be so complex and thus failure-prone. But the myth of SSDs wearing out needs to die. When an SSD does wear out its write endurance, it's a gradual process with lots of SMART warnings and a gradual decline in performance when the controller no longer has enough less slack space to work with, and some sporadic data corruption. It also doesn't start happening until the drive has been subjected to a lot of heavy writing - it takes months of 24/7 torture testing: http://techreport.com/review/26058/the-ssd-endurance-experim...
And yes, I took steps to reduce wear on my SSD, including installing a secondary drive, noatime, disabling local TimeMachine, and using external drives for torrenting. My SSD still died.
Failures range from SSD no longer being able to communicate properly over SATA, to losing chunks of data at random points in time, and freezes.
Depends on your workload.
Mine now frequently involves accessing far more data than will fit into RAM, and thus will fit into the filesystem cache. There are only two options: This either flushes useful data out of the cache, or fails to enter cache in the first place. Either way, I'm going to be hitting either slow to seek spinning platters, or a fast random access SSD, even with a perfect oracle for an OS caching algorithm. Sadly, current OSes seem to be lacking even that.
> Also, as I'm aware it doesn't really help much with compilation performance.
Friends have seen compilation times approximately halve, even without a RAM busting workset (yes, they timed it.) I've personally seen similarly extreme performance gains in compilation, again even without a RAM busting workset. I've seen even better gains for those worksets that do bust RAM, especially if extremely IO bound.
YMMV, but I do not buy or build computers unless I can put a sufficiently large SSD into it anymore. I define "sufficiently large" to include my OS, my tools (IDEs, SDKs, etc.), and a couple of active projects to fit onto. Everything stays snappy. I bought an 80GB back when they were $500, about twice the cost of any other component in any of my computers then or since (ignoring more SSDs), and still consider it money well spent.
I recently bought a laptop - priorities, in order, were: Must have an SSD, should have extremely high resolution (ended up with 1800p, not 1080p), and only after that did I even bother to check if the machine had at least a decent amount of RAM, and a not entirely terrible CPU. It doesn't even have a dedicated GPU, just the little Intel that can do D3D11 at horrifically low framerates. (This despite using Direct3D SDKs both professionally and for play.)
http://shop.lenovo.com/us/en/laptops/lenovo/yoga-laptop-seri...
I should note that it's a pentile display (which is cheating), and 13.3" (which is tiny), but it gets me what I want: The ability to fit as much onto the screen as I can read.
~276dpi is "sufficient" - I'm finally using font sizes bigger than "the smallest that keeps the pixels legible". And to think that originally I was looking for 4K displays...
Even if you still need large storage capacity having the primary drive be an SSD will yield noticeable improvements.
If you are doing any sort of database work with a fair number of writes and/or a dataset larger than fits neatly in RAM, it can make a lot of difference.
Other than that I don't tend to notice much change until I'm trying to do two or more things at once (opening and using other apps while a large build or test set is running for instance), at which point the difference can become pretty significant. With spinning metal other interactive work while that sort of thing is happening in the background is painful, with the SSD there is still some I/O contention but the near-zero latency (due to no head movements) greatly reduces the overall effect. The lower latency often means builds/tests stop being I/O bound (waiting for head movements) much at all and the CPU becomes a more significant bottleneck (particularly for tasks that don't/can't parallelise so are stuck on a single core) further reducing the I/O contention with interactive use (or allowing you to run several of those now-core-bound processes concurrently instead of sequentially).
Although I rarely boot my PC I am running a number of virtual machines and the SSD helps when booting those.