PS CS3 much slower than CS2 on Intel Mac. I don’t get it.

In both CS2 and CS3 the scratch disk is my startup volume, but it’s a RAID.

My guess is that is the problem — and that you would get better performance using the External FWD for Scratch than using a RAID which is shared with the System.

Try using the FWD and see.

I just asked about the RAID versus separate drives issue in another thread.

Nevertheless, would this explain the difference between CS2 and CS3 on the same machine? Wouldn’t CS2 be hamstrung the same way?

Besides, I’ve added dedicated scratch disks to other systems before. Yes, there is a big performance boost, but three to four times faster? I didn’t get that kind of performance increase even adding a fast FW drive to a system with a relatively slow IDE drive.

I suppose I’ll have to go buy a new FW drive to test this out.

I do not know why CS2 is outperforming CS3 on a MP. I have the opposite experience. [How does RAM report out during your tests?]

DO NOT BUY THE FW DRIVE, FW is much slower than the internal SATA or if you were to choose an external eSATA drive. Instead add a Raptor drive internally in the extra optical drive slot and put the System and apps there, with scratch on your RAID array. If you choose not to use the optical bay slot use an eSATA-connected drive.

I agree that you should not partition the RAID. Personally I find the 4 bays of a MP inadequate for me to sacrifice all 4 bays for RAID5 so I have two in RAID0 plus a System/apps drive and an on-site backup drive.

I did get 8GB of RAM; would have gotten more, but I read that it won’t matter until CS goes 64-bit in CS5 at the earliest.

Not true, you will see improved performance with more than 8 GB RAM. Also, do a forum search on "Bigger Tiles" and also on "Force VM Buffering" as one or both will probably be appropriate for your large files.

Allen, what do you mean by "report out"?

I’m testing the RAM using memtest in single-user mode right now. It’s almost finished with the second iteration, so I think five hours of testing is pointing to the RAM being good.

And yes, I think it’s totally bizarre. I only posted here because I couldn’t find a single other instance of a benchmark where CS3 didn’t handily beat CS2 after hours of googling. There’s something very wrong here; it’s just a matter of finding what it is.

I’m considering canceling my CS4 preorder until such time as I can try the CS4 demo and see it run faster than CS2.

Since I work with extremely large files, I got a hardware RAID5 made up of four 15,000RPM SAS drives. I can’t get enough RAM to avoid using scratch disk, so I attacked the biggest performance bottleneck. I did get 8GB of RAM; would have gotten more, but I read that it won’t matter until CS goes 64-bit in CS5 at the earliest.

I’m not sure if your setup is ideal for CS3 (or CS4 when it comes out).

Unless you address all three botlenecks; CPU, Ram & Disk I/O you really don’t have an optimal setup.

Personally, I’m questioning both the ram (8 is on the lite side for CS3 on a MacIntel if you use the VM Buffering plug-in because while limited to 4 gigs/app, Photoshop CS3 _CAN_use more by allowing the free ram to be used for scratch disk buffering).

I’m also thinking that the RAID 5 won’t be really optimal considering that your boot and scratch are on the same logical partitions. Putting your boot on the RAID will only speed up system paging, which if you have enough ram won’t happen much at all. You could have the system and apps on a separate drive and use the raid card to array the other 3 drives. And for speed, I would suggest a 3 drive array using RAID 0–which of course means you would need regular backups to a second drive system.

I have 4 1TB drives internal. The one drive is a simple volume with boot & system, the other 3 drives are arrayed using the OS X Disk Utility in a RAID 0. The first partition of which is a dedicated scratch partition and the rest for image files. This produces a very fast system since the ram is at 16 gigs. Having the scratch drive and images isn’t a problem because scratch isn’t slowed down by opening/saving but the image partition isn’t being used while an image is open so scratch is fast.

I use Retrospect to do nightly backups of changed or added files to an external FW 800 4 drive RAID 5 external.

I can’t spend the time testing against your benchmarks, but I will say that the times you list seem REAL SLOW…on my system, CS3 is FAR faster than CS2 could ever be. Something on your setup is constraining Photoshop CS3 to make it perform so poorly.

Oh, and I wouldn’t bother canceling CS4 because while you won’t get to use more ram, you will be able to access and use your GPU, plus CS4 has a lot of other goodies…but I would seriously look into your set up.

Steven,

Photoshop can occasionally choke on RAM that the software RAM testers pass as OK.

Jeff–

Yes, I know those times are real slow. They are slower than the CS2 times on my single-processor iMac. I’m not suggesting that Adobe released a dog, I’m asking for help troubleshooting this.

About the RAID, I’m unconvinced that having the scratch disk on a separate volume but the same SAS controller will be any different than having all four drives in the RAID. The RAID controller will have to do exactly the same thing that it’s doing now: take the same number multiple requests from multiple processes and distribute those requests among the four drives. The only difference? One of those drives will be substantially slower.

As Allen said, I’ll need to put a drive on a separate controller in order to get any benefit at all. RAID5 is still twice as fast as these drives individually. I could get them to be two and a half times faster than the individual drives by using RAID0; Unless there really is a benefit to having scratch on a seperate *logical* volume (which is how the controller will see the separate drive)

As I understand it, the benefit of having the scratch volume on separate drives is so that you can write to two drives at the same time. Well, that’s what a RAID does… for everything. I don’t see the possible benefit of forcing all my reads and writes except for photoshop swap to be half the speed of the photoshop swap, when I can have all the writes at nearly full speed. We aren’t talking about a single drive here. Unless Photoshop does something magical with a scratch disk, I don’t see how having the system and scratch volumes on the same RAID presents a bottleneck.

If I had two SATA drives, one for the system and another for a scratch volume, or a second firewire drive, no one would be considering that a possible bottleneck. I guarantee either of those setups will be substantially slower than putting both on the same set of four substantially faster drives (ie RAID). Please correct me if I’m coming from outer space here.

In any case, I accept I could be wrong and opened another thread about RAID5 versus separate drives. I very much doubt that having my scratch disk on the system volume affects the speed of CS3 but not CS2. There’s something else very wrong here.

As far as canceling CS4, I could get a zillion more goodies but if it makes my work take three or four times longer (like CS3 does until the problem can be tracked down) it will not be worth it.

Ramón–

Sure, the RAM could still be bad, but how will I ever know? I’ve done what testing I can, and I have tested CS2 versus CS3 with:

A: the Apple RAM that came with the system only
B: the OWC RAM that arrived two days ago only
C: both the Apple RAM and the OWC RAM installed.

in all three of these cases, the results were consistent: the times for resize and rotate for PS CS3 were three to four times longer than the times for the same operations on the same files in PS CS2.

So, sure. It’s possible that I have two batches of RAM from two different manufacturers that have exactly the same bug that doesn’t show up in memtest or Photoshop CS2 but does show up in PS CS3, but that’s stretching the bounds of likelihood, isn’t it?

At this point, the only things I can think of are:

A: PS CS2 and PS CS3 don’t like being on the same machine

or

B: There’s something freaky about Rosetta’s resource allocation where I’ve accidentally hit a sweet spot.

I don’t know. What I find especially strange is the CPU usage. CS3 isn’t even trying.

As I understand it, the benefit of having the scratch volume on separate drives is so that you can write to two drives at the same time. Well, that’s what a RAID does…

Not quite.

The benefit of having a dedicated, separate disk (or RAID set) for PS scratch is that there’s nothing else to interfere. OS X requires it’s own type of "scratch space". With your present setup, Photoshop’s scratch requirements are battling for disk access with the OS requirements – which can slow Photoshop to a crawl. Using a striped RAID for PS scratch will greatly improve performance (over a single, separate scratch drive), but NOT when the OS/System is installed on the same set. For best performance, keep your System and PS scratch on separate drives (or RAID sets).

Listen to Jeff …

What I find especially strange is the CPU usage. CS3 isn’t even trying.

It depends on the task – some operations are CPU intensive but many are RAM / Scratch intensive. To give your CPUs a workout, try processing some RAW files.

-phil

I just trashed all of CS2… I followed the uninstall instructions, got rid of Photoshop, Indesign, Illustrator, all of it. And trashed the PS CS3 demo. Then restarted the system and reinstalled only PS CS3. Then restarted again. Trashed the prefs and opened CS3, then went to my demo image and resized from 400ppi to 800ppi.

It took a little over 35 minutes.

Again, in that time I never saw Photoshop use more than 50% of the CPU and I never heard any constant hard drive usage.

Furthermore, OK, I just took a 2.5GB image and resized it to over 10GB on a system that now has 10GB of RAM. Activity Monitor reports that I have almost 2GB free and that it has used less than 7MB—MB not GB—of swap. For the first 20 minutes I had almost 6BG free. The last 4GB got used up in the last 10 minutes of operation.

So the hard drive is barely getting used, the memory is barely getting used, and the processors are barely getting used. What could be the bottleneck other than memory, processor, or hard drive?

Graphics card? What does the graphics card do for operations like this? Nothing, that’s what.

I don’t have any idea what else to try.

The benefit of having a dedicated, separate disk (or RAID set) for PS scratch is that there’s nothing else to interfere. OS X requires it’s own type of "scratch space". With your present setup, Photoshop’s scratch requirements are battling for disk access with the OS requirements – which can slow Photoshop to a crawl.

OK, lets say this is the issue. Explain how it has been slowed down to the point where the same task takes longer than it does on a single-processor machine with one-fourth the RAM, no RAID, just one 7200 RPM drive serving as both system and scratch.

Are you really saying that using a RAID for system and scratch is slower than using a single hard drive for both system and scratch? Really? Because I don’t believe that.

Are you saying that CS3’s system of using scratch space is so much more vulnerable to the problems of "battling for disk access" that it takes three times as long to do the same task as CS2 on the same machine? Really? Because I don’t believe that either.

Besides, OS X is reporting using less than 10MB of swap space while all this is going on.

Using a striped RAID for PS scratch will greatly improve performance (over a single, separate scratch drive), but NOT when the OS/System is installed on the same set. For best performance, keep your System and PS scratch on separate drives (or RAID sets).

It would have to be a separate RAID entirely with a separate RAID controller to make any difference, wouldn’t it?

It depends on the task – some operations are CPU intensive but many are RAM / Scratch intensive. To give your CPUs a workout, try processing some RAW files.

I don’t care about giving my CPUs a workout. I’m wondering why CS2 does a task in ten minutes using 100-250% CPU and CS3 on the same machine does the same task in forty minutes using at most 50% CPU.

If this really is a problem that can be traced directly to the hard drive being bogged down with requests from different processes (especially a RAID designed to take requests from many more processes than Photoshop plus OS X) then it says something terrible about the programmers that worked on CS3’s scratch disk routines, because CS2 running through Rosetta is kicking the pants off of them. That, I find difficult to believe.

Sure, the RAM could still be bad, but how will I ever know?

By pulling out pairs of RAM sticks in succession.

MISMATCHED RAM can be as troublesome as bad RAM.

I’m unconvinced that having the scratch disk on a separate volume but the same SAS controller will be any different than having all four drives in the RAID. The RAID controller will have to do exactly the same thing that it’s doing now:

No. If the Photoshop scratch disk is in a different volume (other than the boot volume), it will NOT be competing with the OS for the use of the set of read/write heads as the OS builds its swap file.

Please correct me if I’m coming from outer space here.

Did you bring something from out there to cause the stock market to tumble? 😀

Just kidding. of course.

Incidentally, you mentioned trashing CS3. Hope that doesn’t mean you actually dragged it to the trash and empty it.

You can’t do that in CS3 as you could with earlier versions. You MUST use the Adobe uninstaller that gets installed by CS3 in Applications / Utilities / Adobe /.

Routine maintenance is imperative.

I still advocate Repairing Permissions (with Apple’s Disk Utility) before AND after any system update or upgrade, as well as before AND after installing any software that requires an installer that asks for your password.

I have seen software installations go sour because the installer did not find everything as and where it should be.

I have also seen software installations go bad because the installer did not clean up after itself properly and did not leave everything as and where it should be.

This is just my own personal opinion and practice based on my own observations. Others may disagree and that’s OK. I can only base my routines and my advice to others on my own experience and conclusion. I don’t pretend to know why others believe otherwise.

Repairing Permissions after the fact (i. e. not immediately before and after an install) seldom helps.; Try it anyway, though.

====

Additionally, if your machine does not run 24/7 so that it runs the daily, weekly and monthly Cron Scripts in the middle of the night as intended by Apple, run Cocktail (shareware) as well.

Cron Scripts are maintenance routines designed by Apple to run on a daily, weekly and monthly basis in the middle of the night.

If you don’t run them, you WILL run into trouble, sooner rather than later.

Here’s an excerpt from the Apple tech doc <http://docs.info.apple.com/article.html?artnum=107388>

Mac OS X performs background maintenance tasks at certain times if the computer is not in sleep mode. If your computer is shut down or in sleep at the designated times, the maintenance does not occur. In that case, you may want or need to run these manually.

Mac OS X periodically runs background tasks that, in part, remove system files that are no longer needed. This includes purging older information from log files or deleting certain temporary items. These tasks do not run if the computer is shut down or in sleep mode. If the tasks do not run, it is possible that certain log files (such as system.log) may become very large.
Also, from: <http://docs.info.apple.com/article.html?artnum=106978>

The disk activity generated by find is a normal part of file system maintenance, used for tasks such as removing invisible temporary files that are used by the system. It is scheduled to occur early in the morning at 03:15 everyday, 04:30 on Saturdays, and 05:30 on the first day of each month.

NOTE: There have been comments to the effect that Apple "fixed" this in 10.4.2 and later versions of the OS, but I have not been able to verify this to my satisfaction. The reference in the 10.4.2 release notes are far from explicit on this subject.

= = =

If you have DiskWarrior, run it regularly too.

I don’t have any idea what else to try.

You might just try what everyone is suggesting and put your scratch on a separate drive from your OS.

Cindy–

I will, I just have to go out and buy another drive, backup, reformat, etc etc. I’ll do that tonight. However, I still contend that there is no way that this is responsible for the problem without very serious problems in Adobe’s CS3 code. CS2 on the same machine also has the system and scratch on the same drive, and it’s what’s running three to four times faster. My iMac also had the system and scratch on the same drive, and that was a single drive, not a RAID. It too was faster.

So I’m going to rearrange my RAID, and then hopefully we can move on to troubleshooting.

Ramòn–

Thanks for the alternate suggestions. I apologize for misspeaking about "trashing" CS3 before reinstalling. I did see the uninstaller and I did use it.

I have rebooted to the install disk several times during this process to repair permissions and verify the disk. Not each and every time, but I have been doing it.

I also do leave the system on 24/7. I know about the cron jobs but also the RAID doesn’t really like to be stopped and started. The process of reinitializing the RAID takes a long time, so I prefer to avoid it.

As far as the RAM, I said I did pull the pairs out in succession and test each time through. Mismatching could be an issue. I have matched pairs but not a matched quad. The performance hit that’s supposed to cause is pretty minimal–6.5G/s instead of 7.5G/s–significant but unless there’s a race condition sort of thing happening, that doesn’t explain this slowdown.

Not to mention that if it were a problem with the mismatched quad, the problem would go away when I tested with a single matched pair.

My external drive enclosures keep failing so I’m going to go out and buy an external drive or just another enclosure (though I’m getting tired of this route). Either way, by tonight I should be ready to back everything off and rearrange the RAID volumes.

Thanks,

Steve

Allen, what do you mean by "report out"? [regarding RAM]

Certainly your symptoms point to the kinds of issues exacerbated by RAM problems. What I meant was watch Activity Monitor and see what is happening with RAM page outs. If page outs are increasing rapidly during your tests then RAM limitations are at least partially an issue.

If I had your large-files workflow I would buy two (or preferably 4) 4-GB sized matched RAM DIMMs, remove all the existing RAM, and install only the new RAM to test whether or not the old RAM is anomalous. If that new RAM does not improve the operational times then also add in the old RAM.

OWC <http://www.owcomputing.com/> is one very good source for RAM and they have videos of important proper installation protocol. Unfortunately the price of 4-GB sized DIMMs, although falling, is still high compared to the 2-GB size but IMO because of limited slots you should not be adding RAM any smaller than 4-GB size DIMMs.

Any of the things Ramón mentioned also might help resolve your setup’s anomalous behavior.

-Allen Wicks

ght. However, I still contend that there is no way that this is responsible for the problem without very serious problems in Adobe’s CS3 code.

Ya see, this is the attitude you really, really should get over. The Photoshop CS3 (10.0.1) code is just fine… it’s your system (hardware/software) which, for some reason is not providing an optimal environment.

On MY MacPro, CS3 is considerably faster than CS2. If there was a fundamental problem with speed of CS3 on MacIntels, these forums would be lit up with all sorts of speed related issues. They are not. So, reason dictate that something, somewhere on YOUR machine is, for whatever reason, particularly South of optimal. The sooner you quit trying to blame Adobe, the quicker you’ll turn your attention to the far more likely troubleshooting issues.

Ya see, this is the attitude you really, really should get over. The Photoshop CS3 (10.0.1) code is just fine… it’s your system (hardware/software) which, for some reason is not providing an optimal environment.

Jeff, I agree completely. You seem to be assuming that I actually think Adobe wrote bad code. In fact, I believe Adobe did NOT write bad code (and I wrote that) but that the condition that you are suggesting (CS3 being slowed by having having scratch and system on the same volume to a far greater extent than CS2) could only be caused by bad code by Adobe. Since I believe that, as you say, a universal difference of this magnitude between CS2 and CS3 would be noticed by huge numbers of users, I doubt that what I am seeing is the result of having scratch and system on the same volume.

In case I’m being less than clear:

Scratch and system were on the same volume for CS2.

Scratch and system were on the same volume for CS3.

On my system CS2 performs tasks three to four times faster than CS3.

ergo, either there is some problem other than scratch and system being on the same volume (perhaps something that exacerbates the scratch/system/same volume issue, OK, I accept that possibility) or else the change has been between CS2s and CS3s handling of scratch disks.

If for the sake of argument we rule out the possibility that CS3 handles the condition of scratch and system being on the same volume worse than CS2 does, the only possibility left is that there is SOMETHING ELSE WRONG WITH MY SYSTEM.

I am trying to find out what that other thing is. You’re the one insisting that scratch and system being on the same volume is the cause of the CS3 slowdown. Accusing me of not believing that there’s something wrong with my system misses the mark entirely. I ABSOLUTELY believe there is something wrong with my system.

Your RAM tests sound pretty thorough, but if I had your large-files workflow I would buy two (or preferably 4) 4-GB sized matched RAM DIMMs, remove all the existing RAM, and install only the new RAM to further test whether or not the old RAM is anomalous.

Thanks Allen,

Actually, this is exactly what I’ve done, though in a different order. My system shipped with two 1GB chips. I bought two 4GB chips from OWC and installed them, and found my CS2 performance to increase significantly. It was only then that I tried installing the CS3 demo. When I found CS3 running my tests more slowly than expected, I pulled the new RAM out and tried with just the original 2GB and tested both CS2 and CS3 again. Then I took the original 2GB out, put only the new RAM in and tested CS2 and CS3 again, finding the same results. Currently I have all 10GB in the system and for the moment I’m setting aside the possibility of a problem with the RAM (or at least setting aside the possibility that the RAM chips are just plain bad) because that would indicate that both the new and the old RAM are both bad in the same way. That seems unlikely.

So I guess I’ll have to drag the system down to the Genius Bar if I don’t see an improvement from rearranging my hard drives.

The update there is that last night I backed up my system, and this morning I deleted my RAID5 set, blowing away everything on my system until I can restore from backup. The new configuration is 1 JBOD drive plus three drives attached as RAID0.

Unfortunately, neither of the new volumes is visible when I go to restore from backup. For the moment, this little experiment has cost me my entire system. The upshot is that it may be some more time before I have any more information to share. Even when I do get it working again, I can expect restoring to take the same 12 hours that backing up did.

I will certainly post here when I’ve got my system back.

Update: getting my drives visible to Time Machine only required a reboot. It’s all good and my system is restoring. I’ve got a few hours of restoration before I can test CS3 with my system on a single JBOD drive and scratch disk on a three-disk RAID0 on the same controller.

I still feel like I’m going slightly insane because of this thread here. I will very happily eat my words and confess that I was woefully wrong if this fixes the problem, but am I really the only one who finds it farfetched that scratch and system account for that much of the performance hit to CS3?

After my external drive died on my iMac (and up until the day I sold it), I ran CS2 with both system and scratch on a 7200RPM ATA drive. The tests I ran on that setup were *faster* than my tests of CS3 on a four-disk RAID5 of 15,000RPM drives.

Never mind the seven extra processors and the extra 7.5GB of RAM. The OS and PS competing for a slow drive should be slower than the OS and PS competing for a RAID of fast drives. Right?

Am I really just bullheaded to see that as incontrovertible proof that there is something else at play? I feel like I’m putting a bandaid on the elbow of a man with a broken leg and hoping he’ll start running.

Again, I’ll be very pleased if it works and I’m mentally preparing myself to eat crow, but… is that what you really think is THE issue?

Steven,

Speaking for myself, I never thought or said that the separate scratch drive was the only issue you have, and I don’t think anyone else did so. However, it is a significant issue, and one to which anyone should pay attention.

By restoring your system you’ll be eliminating likely directory and fragmentation issues as well.

It just makes sense to eliminate possible causes one by one.

Ramòn–

I wholeheartedly agree that eliminating causes one by one makes sense.

I hadn’t been concerned with fragmentation at all–the Mac EFS (like most modern filesystems) is famously fragmentation-resistant. I’d hope that fragmentation wouldn’t be much of a problem even with a lesser filesystem on a computer less than two weeks old and with a half a terabyte of free space. I expect now that my primary drive will be starting life over again two-thirds full I’ll have to worry about fragmentation much more. But really that doesn’t concern me; it’s a problem fairly easy to address.

If rearranging the RAID does quadruple my speed with resize and rotate operations on large files in CS3, believe me, I’ll be psyched. Relieved, really. But I’ve used separate scratch disks before and seen improvement, but never anything near the 300-400% improvement I’ll need to stop me from canceling my CS4 order until after I can try the demo. The upgrade cost isn’t a fortune, but it’s real money to me. I’ll be happy to pay for feature upgrades, but not a big performance hit.

Not that it’s anyone else’s problem but mine. I was really hoping to find a known issue, easily solved or at least promised to be solved in the future. Still have my fingers crossed, but if none of you has heard of anything and a few days of googling hasn’t turned anything up, I’m probably lugging the Mac Pro down to the Genius Bar so that they can tell me there’s nothing they can do if I can’t reproduce the problem using Apple software. I’m pretty sure troubleshooting Adobe software doesn’t fall under AppleCare, and I’m pretty sure my CS2 license doesn’t give me any technical support options for CS3. Fooey.

Bright side: restoration has only 10 minutes left. I’m sure none of you are as anxious about the result as I am, but I’m betting there’s at least some mild curiosity out there. =^)

Steven,

Forgive me for skipping your last post. Why waste so much time arguing? We can only suggest possible solutions and workarounds, that’s what we do in these forums. What you do with them is not my bailiwick.

Honestly? Because typing something here beats watching the percentage climb on the restore. But also because I have a vague hope that if I explain my thinking that someone can point out where I’m mistaken. Where there is contradiction, we must examine our premises. I’m waiting on empirical evidence and can’t make it come any faster, so please forgive me for indulging in theory.

You’re the one insisting that scratch and system being on the same volume is the cause of the CS3 slowdown.

No…I only think it’s a single factor in not getting optimal speed in CS3. I think the root problem of your CS3 speed issues is a multitude of factors that very difficult to troubleshoot by remote control. The only substantial difference between your system and my system if the RAID card and the RAID 5 setup. Personally, I’m somewhat skeptical of the RAID card solution…

I’m not in love with RAID 5 for a variety of reasons most notably I’ve gone through 3 different RAID 5 solutions in the last 18 months and have had trouble with ALL of them. I just lost a 4 TB LaCie external over the weekend…it was a backup to the internal Disk Utility array and I’ve been running around copying files/folders around while I wait for yet another solution (I’m gonna try a FW 800 DROBO now) as an external backup.

The other difference is that I’ve got 16 gigs of ram and I’m running the Force VM Buffering plug-in so whatever free ram is available is being used by Photoshop as 1st scratch after Photoshop has had its fill. Which BTW I’m running the Photoshop ram percentage at 90% not 100% because it seems a bit happier.

Whatever, you’ll need to do testing and troubleshooting because it’s your system, not Photoshop CS3 that is the root of your speed problems…good luck figuring it out.

good luck figuring it out

The first thing I would do is take out the RAID hardware/software and run with only the OEM hard drive

If that doesn’t work, do Disk Utility RepairPermissions and RepairDisk

Then try a New User

If that doesn’t work you will likely need to Erase/ZeroWrite the disk and install only the OS and Photoshop

If that doesn’t work, let Apple tell you why your new machine doesn’t work after you just wrote zeros to the drive and installed only the OS and CS3 Photoshop from scratch and ran all the updates

I would not bother installing anything CS2 on an Intel/Leopard Mac unless you need GoLive

+++++++

I am not a fan of 3rd-party disk utilities, including Disk Warrior

If I need to run DiskWarrior, the install is toast for troubleshooting, IMHO…

Wasn’t there a major change in memory management between CS2 and CS3?

I seem to remember some Tech Docs and blogs on the subject.

K, I have some more information and a very rough theory. I am now on a single JBOD (system) + 3-drive RAID0 (scratch) setup. And the broad strokes of my testing? CS3 runs faster than it did before I switched stuff around, and CS2 runs slower than before. They’re roughly the same now.

If I’d only run the tests once I’d guess I’d just dreamed them up or used the wrong file or something. But I ran the tests multiple times and I’m pretty sure I didn’t just have a flashback from my youthful indiscretions. So is this pretty weird, or what?

So my crazy fuzzy incomplete theory is this: there’s some specialized process about dealing with large chunks of memory and/or hard drive spooling where Photoshop makes big writes to the hard drive or RAM or both. Since CS2 runs in Rosetta, a lot of that hard drive access may be virtualized, turning Rosetta into the world’s most specialized accidental cache, buffering the requests and then does whatever it was supposed to do in a 64-bit multiprocessor-tuned space significantly faster than Photoshop could sitting in its puny (tongue in cheek there) 3.5G of addressable space, when it has real control over (whatever that resource may be) and has to wait for whatever it is to finish before loading up the next chunk into memory and spitting it out to (whatever that resource may be).

It’s vague, I know. But the tests suggest that when the system drive access got slower and the scratch disk access got faster, CS2 in Rosetta got slower and CS3 got faster. It would be something that would only show up in the combination of enormous files (60,000 by 60,000 pixels is a lot bigger than almost anyone works with) and a fast system drive where the idiot who set up the system set the scratch disk to the system drive.

If the added layer of Rosetta meant writing to the the system disk in larger contiguous chunks, that would have hidden the issue of the drive heads having their attention divided. But with the slower non-RAID system disk, it wouldn’t matter because it would be slower anyway.

Put even more vaguely, I may have stumbled on a synergistic effect of three (or more) things done wrong that accidentally clears out a bottleneck a for a specific and unusual set of requirements. That’s a stretch of the imagination, but I’m having trouble coming up with simple and easy explanations for what I’ve observed.

CS3 on my big-file tests is still coming up about half the speed that CS2 was giving me back when everything was one big RAID5, but I think I’m ready to chalk it up to a fluke. Though I hadn’t mentioned it, my tests on smaller files ("only" 250MB) in all my configurations have shown CS3 to be faster or sometimes only equal. Shaving 30 seconds off of a 90-second operation sort of got lost in the shadow of adding an hour to a half-hour operation.

So I’m about ready to call it quits, chalk my fast CS2 times up to a fluke, unrepeatable without going back to a single RAID5 setup and sacrificing other areas of performance. I’ll celebrate making CS3 twice as fast and sweep under the rug the memory of having seen CS2 go even faster because I won’t be using CS2 anymore anyway.

Steven-

Thanks for reporting back, your scenario is curious.

I may have stumbled on a synergistic effect of three (or more) things done wrong that accidentally clears out a bottleneck a for a specific and unusual set of requirements.

Agreed. Also try various memory allocation settings like Jeff did. And what will be really interesting is how CS4 compares; hopefully much faster.

Thanks for reporting back, your scenario is curious.

It gets curiouser and curiouser

And what will be really interesting is how CS4 compares; hopefully much faster.

Good news: CS4 arrived today. My tests on that same file come in at:

5:08 for the resize, 17:43 for the rotate

Twice as fast as CS2 (under Rosetta) on this same machine (tho with a different configuration). Four times faster than my fastest run of CS3 on this same machine.

It may be lazy thinking on my part, but I’m tired of running tests. I am convinced that there is some serious flaw in CS3’s memory handling; a flaw that was introduced in CS3 and fixed in CS4. I don’t know what else explains this. I could say "configuration error" but that’s pretty vague and while it’s conceivable that a configuration error could affect only one version of one piece of software, even that indicates a susceptibility to a particular configuration error not present in CS2 or CS4.

First glance verdict: glad I bought CS4, sorry I even bothered messing around with CS3. Huge waste of my time (and everyone else’s. Sorry about that.)