try purging histories and undo prior to saving. Also, if you can live with fewer history states and levels of undo, then lower these settings. They seem to eat up RAM, and slow things down.
Saving speed is more dependent on drive speed than either RAM or CPU usage.
It will also depend on the file format (eg: compression adds time) and some of the options in the preferences (eg: backwards compatibility)
are you saving on a network or is the save folder shared?
thank you for your suggestions. I uninstalled 7 to trial run CS to see if it would behave differently. I found changing file formats effects save time dramatically, while some don’t save at all.
The file types that I commonly use are .psd, .jpg, .tiff. Jpeg seems to work well- when something is being saved the task manager shows photoshop using 100% cpu time. PSD files are processed by with an immediate CPU spike at about 17% followed by intermittent delays and alternating 2% CPU usage by the application. During the delay period the task manager alternates between showing photoshop as "running" and "not responding". Total time for save of 60MB is about 2 min.
TIFF files on the other hand immediately lock up the program on saving. Please note there is no history to purge. I can simply open the file, perform 1 operation and hit save- photoshop is now "not responding". These are single layer files without compression.
I have (2) 80gig SATA drives in a raid 1 config. I am saving to a folder on my HD.
James, is the scratch file on the raid 1 array?
Chris Cox, have you tested that configuration?
Yes- I have just the 2 HDs and the scratch file is part of the mirror set. What needs to be done to test that configuration? Is that config a bad idea?
We’ve tested it – but it’ll depend a lot on what software was used to setup the RAID.
It sounds like he’s having driver/RAID hardware problems.
