I have recently moved from PS CS5 to CS6 and have noticed what seems to be an increase in the amount of time it takes to save large files. At the moment I am working with a roughly 8GB .psb and to do a save takes about 20 minutes. For this reason I have had to disable the new autosave features, otherwise it just takes far too long.
CS5 managed to save larger files, more quickly and with less memory available to it. Looking at system resources while Photoshop is trying to save, it is not using its full allocation of RAM specified in performance preferences and there is still space free on the primary scratch disc. The processor is barely being used and disc activity is minimal (Photoshop might be writing at 4mb/s max, often not at all though according to Windows).
I am finding the new layer filtering system invaluable so would rather not go back to CS5. Is this is a known issue or is there something I can do to speed up the saving process?
Many problems in CS^ are traced to the video driver. Make sure you have the latest version.
If you have a lot of layers your 8mb file can go huge.
In this case you can use background save. You have to start this with File/save or save as and the you can do other things while it work in background. If you have this opton enabled.
20 minutes still sounds like a long time - even for 8Gb. Are you saving to the same drive you use for Scratch space? Having separate drives for a) OS & program files, b) data, and c) Photoshop Scratch would at least prevent simultaneous read/write operations to the same drive.
Thanks for the quick replies.
Noel: I did actually experiment with turing off 'maximize compatibility' and compression and it had both good and bad effects. On the plus side it did reduce the save time somewhat, to somewhere a little over 10 minutes. However it also had the effect of gobbling up ever more RAM while saving, only leaving me with a few hundred mb's during the save process. This is odd in itself as it actually used up more RAM than I had allocated in the preferences. The resulting file was also huge, almost 35 GB. Although total HD space isn't a problem, for backing up externally and sharing with others this would make things a real headache.
Curt: I have the latest video driver and keep it as up to date as possible.
Trevor: I am not saving to the same drive as the scratch dics, although my primary scratch disc does hold the OS as well (it's my only SSD). The secondary scratch disc is a normal mechanical drive, entirely separate from where the actual file is held. If during the save process my primary scratch disc was entirely filled I would be concerned that that was an issue, but it's not.
Noel: I have 48 GB with Photoshop allowed access to about 44 of that. FYI my CPU's are dual Xeon X5660's and during the save process Photoshop isn't even using 1 full core i.e. less than 4% CPU time.
I'd say with 48 GB and a file that saves 35 GB uncompressed, you still have too little RAM to work on a file that large, and Photoshop has to go to its scratch file constantly during the save process. Thus the process is likely I/O bound.
I have a good workstation, not as powerful as yours but with a giant SSD array that can sustain 1.7 GB/second throughput. I just reproduced what you did, using a bit smaller image (I only have 16 GB in my system). I watched the Resource Monitor and Task Manager.
Just doing a couple of editing steps on the image filled the RAM and wrote the Photoshop swap file to the tune of 30 GB.
Compressed, the save took 10 minutes and was CPU-bound, starting fast but settling to around 8 MB/sec and it was busying around one core (not unreasonable, considering how compression has to be done).
However, with compression DISABLED, the save completed in 2 minutes and sustained around 200 MB/sec writing to the disk, and the file ended up being 21 GB.
The question needs to be asked: Do you really need to work with files that large?
That could be the issue. The odd thing is I've worked with files almost twice the size (compressed, I never tried saving as uncompressed) in CS5 on the same machine when I only had 24 GB of memory. Saving took several minutes, but nowhere near the 20 this is taking. There may be other aspects to the file that cause such a difference in save time that I'm not aware of. This file happens to be 16 bit while the other was only 8, maybe that has some effect. As it is I need total HD space more than speed and so RAID arrays aren't an option.
I do need to work with files this large, if not ever larger (resolution wise). Luckily at some point I will be satisfied with the 16 bit elements and can convert and continue in 8bit. That should hopefully speed things up a bit.
OK, I had to try it. The largest PSB file I had was 1.5Gb (for a two meter revolving advert in an airport) It had several layers and was 20,000 pixels wide. I upped it to 30,000 pixels, changed to 16bit, and didi several copy merged layers running artistic filters on each copy merged layer. It suddenly went from 3.5 to 13Gb in Photoshop, but is 8.7Gb on the hard drive.
I left all the save settings at default, and it took 10minutes 50 seconds as a background save in CS6. Which was frankly longer than I expected.
OS drive 256Gb SSD
Data drive 2 x 1Tb WD Green in raid0
Scratch reserved to 150Gb 10K rpm Velociraptor
Incidentally, I thought I'd check system usage when reopening the 8.5Gb file (see below) and it only took about 90 seconds to load) I was not able to use Photoshop during that time, but everything else worked fine with no apparent lag.
Since Photoshop crashed last night during one of its epic saves I've decided to go down the no compression route for the moment. It'll have to be temporary until I convert to 8bit as with just a few more layers the file has passed 50GB, which is rather inconvenient. Maybe saving up for a Revodrive is the answer.
I'd advise against an OCZ Revodrive. I considered it but built a RAID 0 array of four OCZ Vertex 3 480GB SSDs instead. It provides better performance and more storage for less money.
However, keep in mind that with 1.7 GB/sec capability on tap, Photoshop only pushed 200 MB/sec of data during an uncompressed save.
Europe, Middle East and Africa