<Having a dedicated disk for scratch would be a good start in itself. OS/Apps, pagefile, scratch, source and destination disks for media editing, separating all these things can help. >
I'm currently running OS and app's on a Raptor. Can't say enough about excellent performance coupled with 3.2 P4 running on 875P chipset at 800 Mhz FSB! Data and scratch disk are set up on separate partitions on an older IDE Seagate drive so "normal" editing operations and so forth move right along although the transfer rate of the Seagate dogs when batch processing large numbers of layered files, especially scanned files.
<But given a sensibly configured system already, going to RAID 0 for the scratch disk could provide a significant boost, especially if you already know you're hitting the scratch disk hard, and you can't reduce the number of layers/undos etc. to reduce dependence on scratch.>
This is what I've suspected. Batch processing to flatten layers in numerous large scanned files in particular is in itself one of those things that often causes scratch disk to be used. The hidden price of automation, I suppose!
<For most single user tasks, RAID 0 isn't worth it. But there are still a few things that do benefit from the better STR. As long as you've already separated your concurrently accessed datasets, then RAID 0 can provide an additional benefit when working with very large files (hundreds of MB).>
Will give it a try. Now if those SCSI controllers weren't so darn expensive...