Archive for March, 2006

Macintosh and the Intel switch.

By now you have probably figured out that we aren’t releasing Universal Binaries of our current application versions.  If you haven’t, all you need to know is pretty explicitly spelled out here.

“But, c’mon”, I hear people saying, “Steve said it was just a recompile!”  Or, “Back during the PowerPC transition, you guys released a patch!”

Well, this time is different.  And I really wish it weren’t.  But let me tell you how…

When that original PowerPC transition was done, Apple did something clever.  Very clever.  The emulator that ran 68k code would recognize when it was calling out to PPC code, and would fiddle with things on the stack using the Universal Procedure calling vector.  A lot of gobbledy gook meaning that a 68k binary could call out to PPC code that could then execute at native speeds.  Well, for those that don’t know, Photoshop has a bunch of routines all tucked away to do the real heavy lifting – the bottlenecks.  Most of Photoshop’s CPU time is spent in these routines.  Even better, you can replace these routines using a plug-in.  There’s the Multiprocessor extension plug-in, which replaces some routines with ones that know how to divide work up among multiple processors.  And some which use the multimedia instruction sets that are available to varying degrees on different processors.  And, in the case of the PPC transition, we could replace them with PPC native versions.  With a plug-in, Photoshop could get a majority of the speed up as if it were a fully native application, but – and it’s a key point here – without having to recompile the vast majority of the Photoshop code, along with the resulting testing hit, mounds of debugging, and everything else that would imply.  Most of the gain with a fraction of the cost, it made sense to do a mid-cycle update consisting, essentially, of that plug-in.

Doing that this time around was just not possible for a variety of reasons.  It means is that this time, there’s no limited-cost option for getting most of the performance available on the platform for Photoshop in a short amount of time.  In other words, no shortcuts.

That leaves doing the work for real – taking the whole application over into XCode and recompiling as a Universal Binary.  And that’s no small task.  You see, as software has matured so have the development environments we’ve used – Visual Studio and Metrowerks – they’ve adapted to handle the ever-growing applications using them.  From having projects with large numbers of files that open quickly, to having compact debugging information, to having stable project formats that are text-merge-able in a source control system.  These are things XCode is playing catch-up on.  Now, Apple is doing an amazing job at catching up rapidly, but the truth is we don’t yet have a shipping XCode in hand that handles a large application well.  And switching compilers always involves more work than you would think in a codebase of this size.

Now, I’m an engineer, and I’m all for getting products out in front of customers so they can use their machines to their fullest as soon as possible, but there is just no way putting out a Universal Binary of Photoshop CS2 would make any sort of sense.  If you think about switching tool sets, with the resulting huge amount of work for both engineering and quality engineering, if you think about how far past the Photoshop CS2 release we already are, and if you include not having the workstation-class machines ready yet, I think you’d have to agree – far better to focus on making sure Photoshop CS3 is able to absolutely squeeze every ounce of power out of what I’m sure will be pretty spankin’ Intel-based towers by that point than to do tons of work moving an old code base to new tools.


Reap what you Measure

You reap what you measure.  Measure twice cut once.  Don’t tweak without measuring.

So you want Photoshop to perform faster?  You’re gonna want to measure.  But measure what?

There are many things on a system that can go wrong.  You can run out of RAM, a disk can be going bad, you can be bottlenecking on that disk, and you could, in fact, simply be trying to do too much at once.  Unless you watch most of this at once, you’re not going to know what could be going wrong.

Fortunately, both the Macintosh and Windows systems have tools available – built-in or easily available – which measure most of what you need to know.  On Windows, I use the built-in Performance Monitor.  On the Macintosh, there’s Activity Monitor, but I personally prefer a great little application called X Resource Graph, because I like the visual history of the strip chart format, and it has most of the indicators I like to use. 

On the Windows side, I have a standard set of things I like to map on each machine.  I use a consistent color scheme, so that I can go from machine to machine and just glance at Performance Monitor and know what I’m looking at – if you only have one machine, this may not be an issue for you.  I choose blue for memory, red for processor (and green for a dual processor system), yellow for networking items, and various of the dark colors for disk items, with a dashed style.  I map both Available KBytes and Available MBytes so I can play the dual-sensitivity trick – I adjust the scaling on Available MBytes so that the blue line is somewhere in the middle of the strip window, adjusting the scale on the graph so that the blue line ends up somewhere between 10 and 100 (on a machine with 1GB, you’ll end up with it somewhere in the upper half using 0.1, on a machine with 2GB to 5GB, you’ll end up with it in the bottom half using 0.01), then I adjust the scaling on Available KBytes to match, then set the scale to 0.001.  What this does is give you a gross-level idea of free memory on the system, and when memory gets below 100MB free (the danger zone), you get a detailed view.  For each physical disk, I like to add % Disk Time, I set the line style to dashed and a dark color, for no particular reason beyond that’s the way I’ve always done it.  And of course, mapping % Processor Time to a big bright red is to make it obvious.  I then hit the General tab and turn off all the Display Elements.  You may need the legend turned on until you’ve learned what all the colors are, but I’m used to this setup by now, and it lets me have a real uncluttered window with no wasted real estate.  While I’m there, I set the update interval to something useful like 5 seconds.  Yeah, it’s not as much fun to watch that way, but you can usually get a better sense of tends over time this way.

Once I’ve done that, I go back into the Performance Monitor part and use View / Customize View to turn off everything.  I then go into File / Options and set Console mode to User Mode, limited access, single window.  I then use File / Save As to save out perfmon.msc, putting it into my Documents and Settings\<USERID>\Start Menu\Programs\Startup folder, so that it loads up when I log in.  Yeah, you could save it somewhere else and open it when you need it, but I find that having it up all the time is a big advantage.  I then close Performance Monitor, and select perfmon.msc from the Start Menu, All Programs / Startup (you’ll see it there if you saved it there in the previous step).  That gets you this nice, clean, compact monitor window that you won’t mind always having up and that you can glance at (when it’s not buried behind the Photoshop main window – it’s a great window to go along with all the palettes on your new second monitor  and see what’s going on.

On the Macintosh side, things are a little easier.  You can go with the standard Activity Monitor, in which case I’ll leave it up to you to figure out where to watch, or you can install the excellent X Resource Graph, which will let you quickly map all the items you need, and again has a nice strip chart format that gets you that sense of history that can often help figure out what’s going on.  I know some of the folks around here like some of the other monitor programs, but when I glance over to see what’s going on, I don’t need to try and have me brain interpret fancy colored circles on anything.  The key thing here again is turning on enough items in the preferences, and set up a color scheme you like.  Again, I set this as one of my login items.  I really like X Resource Graph’s ability to stalactite/stalagmite some of the graphs, but I really wish I could have a strip graph of the memory items instead of the paging graph (well, in addition to, really).  And as on Windows, I like to slow down the refresh time to once every five seconds, to get a reasonable amount of history into those strip charts.  There are color schemes which you can download which aren’t so colorful, and won’t be so intrusive on your image editing, and I usually have mine set up a little more subdued than this.  And again, it’s a great thing to tuck over on that second monitor.

On both systems, the question becomes, just what are you looking for?

Well, let’s start with memory.  Photoshop uses a lot of memory.  And it has it’s own virtual memory systems because it has to deal with data sets far larger than the address space allowed to 32-bit applications (and we can’t just do a 64-bit version and it’s still not clear if it’s worth it), plus additional reasons I’ll cover some other time.  What it means is Photoshop is going to use the memory percentage of free RAM you’ve told it, and try and live within that amount.  What’s key here is that while living within that amount, you really, really don’t want the amount of system free memory to get below 20MB.  What happens if you get somewhere below that amount of free RAM (the exact amount shifts around between the operating systems, and there are other variables – 20MB seems to be a reasonable safe zone on both platforms) is that the operating systems start trying to get free RAM back by paging out some things.  Well, given that Photoshop at that point is probably occupying most of that RAM that the operating system wants to reclaim, it’s highly likely that parts of Photoshop memory will get paged out.  Well, when Photoshop then goes to try and operate on the part of the image that was in that memory that got paged out, it has to wait for it to get paged in.  Even worse, if the system paging file and Photoshop’s scratch file are on the same physical drive (meaning you only have one set of drive heads), what will often happen is that Photoshop wants to read a new tile into memory from it’s scratch files, but the memory it’s trying to read that into has been paged out – so a little gets paged in (operating systems have annoyingly small page sizes), Photoshop continues trying to read in it’s tile, a little gets read in, then more of the place it’s trying to read it into needs to get paged back in, then a little more gets read, then…  Well, you get the idea.  Now, when both Photoshop scratch and the paging file are on the same physical disk, each of those little flips between reading the scratch file and paging in the memory to read it into forces the drive head to go to that part of the disk.  Photoshop will now be running about the slowest it could run on your machine.    So, let me repeat myself.  You really, really don’t want free RAM to go below 20MB.  Complicating matters are the filters that like to allocate a single chunk of memory to hold the part that’s going to be operated on.  You’ll know these filters because memory will get used up in a big chunk.  Photoshop will try and be good about giving up tile memory to trade in, but it’s probably not getting it all back (I’ll cover that some other time, too).  If you use those filters often (or if you use a few other memory hungry applications at the same time), then your overall session performance may be better if you back off on the Photoshop memory percentage.  Again, the key is that free memory not go below 20MB (I think I heard that somewhere else before… ).

The next thing to watch for is disk.  There’s disk activity, of course, related to paging activity which will also show up in the paging graphs.  And then there is disk activity related to reading files, and related to reading scratch.  The latter is more interesting, especially as it relates to CPU usage.  Kick off a global filter on a big file, and depending on what the filter is, you’ll see a bunch of CPU activity, then a bunch of disk activity.  There should be very little paging activity during this period (you did watch that free memory amount, right?).  Shortening the period of time the CPUs are waiting for the disk would be the purpose of setting up a RAID array for scratch, if you’re so inclined.  You’ll notice that on a heavily fragmented disk, the disk read amounts won’t form a smooth graph.  To avoid scratch file fragmentation, setting up the Photoshop scratch on it’s own disk is a good thing to do. Concentrating on scratch over actual file open/save reads and writes is preferable because you are usually exercising the disk for scratch usage many times more than for file reading and writing.  It’s often instructive to watch how what you are doing in Photoshop affects the CPU and disk activity.

So, who else is hogging all that memory anyway?  That’s where Windows Task Manager or Activity Monitor can come in handy once in a while.  Simply bring them up (and switch to the process tab in Task Manager) and look for the other applications which are using big chunks of memory.  Sometimes, you’ll find surprises there, like e-mail programs taking up 80MB, or a web browser eating 40MB, or an MP3 player taking 60MB (yes, these amounts seem big to me – but I don’t know what’s going on inside of them, they could be being efficient, but I doubt it).  Now, if you run Photoshop occasionally, and you want to keep those other programs running, no problem – just turn back Photoshop’s memory percentage.  With that level of use, tuning Photoshop’s memory percentage to the last megabyte isn’t going to buy you enough over that short a term to justify the likelihood that you’ll get below that magic 20MB free number.  In the busy machine case like this, less is often more.  If a machine is used to run Photoshop, pretty much Photoshop, from morning to night, then watching and tuning the memory percentage is definitely going to save you some time over the long run.  And, even better, if there are unavoidable reasons why your machine acts slow sometimes (like a disk is already busy even before you start saving a file) you can catch it and plan for that inevitable coffee break.

Note that there are side issues, such as the current pause on Macs with more than 4GB of RAM in them (a stale leftover of the Unix days is kicking in and spoiling the fun – the disk cache that Photoshop writes the scratch file through in large memory situations is getting flushed occasionally, and the operating system ends up forcing Photoshop to wait until that’s done), but this should get you started with the gross-level tuning of your Photoshop environment that is fairly easy and, best of all, cheap.