Points in Focus Photography

Profiling Photoshop Scratch Disk Performance: Stitching a 45MP Panorama

0

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).

Device Access Time
Bandwidth
Modern Mainstream RAM
(DDR-1333)
60 ns 8.3 GB/s
Theoritcal Maximum of a SATA disk
(Generation 3, 6GB/s)
n/a 600 MB/s
(0.6 GB/s)
Fast Solid State Disk
(240GB OCZ Vertex 3)
65 us
(65,000 ns)
~470 MB/s
Fast SATA hard disk
(3TB Hitachi 7k3000)
8.2 ms 157 MB/s

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.

Comments

Tad

It in not comment, just some thoughts. 64 bit Photoshop has some non-active things comparing to 32 bit version. Maybe it woud be better to use 32 bit Photoshop on 32 bit OS, maximize ram to max that MB could handle and do ram-disk as scratch disk for Photoshop only. For. eg. put 16 GB ram to MB, Photoshop will use only 1,6 GB because of it’s limit, build ram-disk for scratch using 10 GB leaving rest for OS. May this be better than using SSD disk for scratch? What you think?
Regards, Tad.

    V. J. Franke  | admin

    That won’t work the way you described it.

    Under a 32-bit OS you can only address 4GB of physical memory (it’s more nuanced than that, but the edge cases just complicate things), and no application can use more than 2-4 GB of virtual address space regardless (the actual size varies by OS and configuration options). Therefore, that option is right out.

    Under a 64-bit OS you’re a little better off, both because the OS can address the full amount of physical memory, and because Photoshop will be able to use the full 4GB of its 32-bit address space before it has to start hitting the scratch disk.

    Personally, I would avoid a RAM disk under any circumstance. The short of it, is that while RAM disks can improve performance in certain corner cases—this isn’t one—they are more brittle and far far far more work to configured properly such that they’re both useful and don’t have unintended performance consequences. Moreover, if there’s RAM available (say from having 16GB in a 64-bit OS and running the 32-bit version of PS), the PS temp files will be held in the OS’s disk cache (RAM) anyway giving the same performance as the RAM disk solution; if there isn’t any RAM available, there wouldn’t be enough room in the RAM disk scratch disk either.

    An SSD is a much better option than a RAM disk, in my opinion. It won’t be quite as fast, but it will be more reliable and less susceptible to configuration errors. Better yet, the OS already knows how to deal with it in an nearly optimal way.

    That said, you’re far better off using a the 64-bit version of PS for the bulk of your work, then dropping into the 32-bit version only for the things you absolutely need that aren’t available in the 64-bit version, and backing the scratch with an SSD.

    If you don’t mind, what functionality are you missing in the 64-bit version of PS?

Our cookie and privacy policy. Dismiss