I’m taking a quick break from the strictly photographic stuff for a moment to look at a computer issue that’s near and dear to our hearts, Photoshop performance.

One “optimization” I see trotted out a lot when people ask about Photoshop performance is to move the scratch disk to another drive; worse yet, make a RAID0 array and put the scratch disk there. Thanks to my background in computer engineer, I’ve always consider this, at best, useless advice. If performance is the goal and you’re touching the disks, you’ve lost before you even begin.

Before I begin, allow me to give a quick primer on the computer bits.

The Problem with Disks

Put simply the problem with disks is they’re slow. Old disks are even slower. Even the fastest disks are more than an order of magnitude slower than the main system memory (RAM).

To put it another way, for people fortunate enough to have an SSD, the system RAM can only move just over a megabyte before the disk can respond. For people using state of the art spinning disks, the system’s RAM will have transferred more than 136MB of data before the disk can even respond. Moreover, RAID does nothing to lower the access times, in fact it often increases them.

Old disks are even worse. I recently benchmarked as pair of 7-year-old SATA disks that I was getting ready to decommission. Their individual average transfer rate (bandwidth) maxed out at about 60MB/s, the seek time was more than 20ms. In RAID-0 (which maximizes the ability to read and write data to the disk), they were barely comparable to a considerably newer, but still middle of the road, 1TB 7200 RPM disk. To put numbers to that as I did above, in the time it took the old disks to even respond, the system RAM could have transferred 340 megabytes. Even with RAID-0 in play, the seek time absolutely kills any performance gain for doubling read/write bandwidth.

Reads Kill, Writes are Free

Modern OSes and the programs that run on them, generally write asynchronously, which means writes are “fire and forget” operations. When Photoshop writes changes out to the scratch disk, it simply tells the OS, “here’s the data, write this to disk,” then continues on doing whatever it was doing. There’s no delay to the image processing that’s going on as long as it doesn’t have to read back that data from the disk.

In actuality, there’s a fair bit more complexity to it than just that, but the short of it is, so long as Photoshop is only writing to disk, and not reading the data back, you won’t see any difference in performance.

Profiling Photoshop

While it may be fine that my gut says for better Photoshop performance, throw RAM at it and screw the disks, I can’t actually say that’s what should be done in reality without metrics, and that means testing. So having had torn my disk subsystem apart recently in an attempt deal with some ailing, and very old, disks I reconfigured them in a couple of ways to do some benchmarks, then I spent a bit of time profiling Photoshop’s workload on my machine.

For the tests, I created an isolated scratch disk, this was to insure that no other processes would show up on the performance counters while I was testing, and then started trying to figure out some Photoshop workloads.

The question is what should the workload be? I don’t do a lot of work in Photoshop anymore, what I do use it for a lot are stitching panoramas and generating HDRs. For this run, I elected to monitor the system while stitching a 45-megapixel panorama. Ultimately, the file if not flattened would consume approximately 1.5GB of disk space, so I’d consider it a very large file, at least based on what I do.

The above chart, you may want click it to enlarge it, tracks several features. The most important in the case of performance are disk reads (red) and Photoshop reads (orange), both measured in megabytes per second. The blue line is Photoshop’s memory usage in gigabytes. The two green lines are Photoshop’s disk writes (light green) and writes to the scratch disk (dark green), again in megabytes/second.

Notice anything?

On a system with 8GB, with Photoshop set to use up to 4.5GB, both the scratch disk and Photoshop process disk reads are virtually non-existent, at least during the time when Photoshop is doing something we care about performance wise. Yes, there are reads when it loads the files.

The only two interesting spikes, at 23:58:35 and 23:59:35, are barely worth talking about. They’re well below any threshold that would be performance limiting.

Conclusions, For the moment

First, solid-state-disks absolutely dominate spinning disks. Even if you were to RAID-0 together enough spinning disks, to match the throughput of an SSD, you never will match the access times and that is the real killer. There’s no point buying spinning disks for anything other than data-storage.

Second, reusing old hard disks as a dedicated scratch disk is probably a bad idea too. Even though it may remove some of the I/O contention from other drives, they likely will be considerably slower than a new disk. Moreover, if you’re going to spend a $100 on a new disk for your scratch disk, you’re better off putting that into an smallish SSD than a spinning disk.

Third, RAM is king, as it should be. There is absolutely nothing you can do with your disk subsystem to improve Photoshop performance that comes close to having enough RAM to cover your workloads. In fact, I wouldn’t even bother fiddling with disks unless I had already maxed out the RAM my system could handle, and if that was less than 16GB, I’d seriously look at a new computer with a 64-bit OS—there’s no point putting money into a dead end platform.

Fourth, disk performance doesn’t seem to be fully utilized even when the capacity exists. The disk I used as a scratch disk for this test is capable of random writes in excess of 50MB/s, yet Photoshop never pushed more than 28-30MB/s.. Maybe it was an artifact of small random writes, or some other characteristic of how Photoshop was writing data out. Either way, at least in this case, having really fast disks woudln’t necessarily help (not that it matters), though it would mean potentially longer waits before a read can be made if you are unfortunate enough to have to make them.

Fifth, you don’t have to figure out Performance Monitor (or the Mac equivalent) to do this, Photoshop includes a very useful “efficiency” metric in the info panel at the bottom of your documents. An efficiency of 100% indicates that Photoshop is working entirely from RAM; a lower number indicates that Photoshop is reading data back from the scratch disk. If you never see the efficiency drop, or only do so rarely, messing with your scratch disk isn’t going to help anything.