Mac OS X 10.3 Panther

It's that time of year again. For three consecutive years, Apple has released …

Performance

Panther is faster than Jaguar. There are a few ways to look at this. First, there's the boring, old world of numerical performance. You know, benchmarks and all that jazz. Panther wins these mostly on a technicality: gcc 3.3 produces more optimized code, and can better leverage the G5. Panther itself is built with gcc 3.3, so there you go.

But "perceived performance" is where Mac OS X has always suffered. As far as the user experience is concerned, if it "feels slow," it is slow. Panther has improved here as well. I am hard-pressed to find any part of the user interface that does not feel noticeably faster in Panther than it does in Jaguar. It's as if the cobwebs have been removed from the OS. There are far fewer "uncomfortable pauses" in the UI. Animations have fewer frames, and therefore complete faster. Yes, even windows resize slightly faster.

This is mostly the result of optimization in a handful of very common operations. In particular, almost everything having to do with text (measuring text, text layout, text rendering, etc.) has gotten a significant performance boost in Panther. This sounds like a pretty boring optimization, but it really pays off.

Here's another way to look at Panther's performance. For over three years now, Mac OS X has gotten faster with every release—and not just "faster in the experience of most end users", but faster on the same hardware. This trend is unheard of among contemporary desktop operating systems. It certainly didn't apply to classic Mac OS, where every significant new OS version was perceptibly slower than its predecessor on the same hardware. (Yes, System 7 and Mac OS 8, I'm looking at you.) The world of Windows follows a similar trend. It is usually taken for granted that a shiny new OS will not really sing until you upgrade your hardware.

Not so with Mac OS X, as my blue and white G3/400 can attest. It has hosted every version of Mac OS X ever released, and the darned thing just keeps getting faster.

Of course, the more pessimistic angle is that Mac OS X's performance had nowhere to go but up! And like System 7 and Mac OS 8 before it, Mac OS X is indeed perceptibly slower on the same hardware than its distant predecessor, Mac OS 9. But I'd argue that the 10.1-to-10.2 and 10.2-to-10.3 transitions were at least as significant, as measured by lines of code changed and new features added, as the transition from System 6 to System 7, or System 7 to Mac OS 8. I think it is fair to give Mac OS X some credit where credit is due.

Part of the reason for classic Mac OS's slow evolution and generational performance dips is the nature of the code. Classic Mac OS is a tangled wad of phone cord next to Mac OS X's neatly-ordered spice rack. Mac OS X changes so significantly and improves so rapidly because it can. Whole subsystems are refactored, recoded, or resynchronized with work done elsewhere (e.g. FreeBSD, XFree86, OpenSSL, etc.) to a degree that would (and probably does) make a classic Mac OS programmer's head spin.

For those who haven't been paying attention, this is the big pay-off for going with the Unix-based NeXT platform as the basis for Apple's new OS all those years ago. It gave Apple a modular Unix-flavored foundation that is well-understood by legions of smart developers, many of whom Apple quickly (and smartly) scooped up and put to work on Mac OS X.

At every WWDC, I am more and more impressed at the sheer volume of "stuff" that has changed under the hood in each new Mac OS X release. Seemingly everything is up for grabs. The potential down-side is that Mac OS X developers must be nimble in order to keep up with Apple's OS developers. While Apple is good about maintaining existing APIs, the new APIs are often so compelling that any developer who does not adopt them is at a competitive disadvantage. It seems that only the strong will survive.

Window management

Now for a sobering dose of perspective. While Panther is indeed faster than Jaguar on the same hardware, it is still not nearly fast enough in many areas. Those darned cobwebs have not been fully excised from Panther. Window manipulation in particular still sometimes pauses, stutters, and generally lags behind my mental state.

Yes, this does indeed include our old nemesis, window resizing. While the window resizing speed on a beefy G5 is acceptable, I am left to wonder exactly what is (still) gumming up the works even a little. Is the system CPU-bound as it renders the window contents "in software" rather than on the video card? Is memory bandwidth still an issue on a Mac with a 1GHz memory bus? Is the real culprit IPC overhead related to the window server? I am fresh out of ideas. It seems clear that this "problem" will eventually solve itself as Macs (finally) start to get faster, but we're not quite there yet.

Clutter, an application that creates a small window for each album in your iTunes music collection, provides a good stress-test for window handing.

Clutter: about 130 windows (some overlap)

Simply showing and hiding the Clutter application (and all of its windows) takes about 1.5 seconds on a dual 2GHz G5 with 1.5GB RAM and 128MB of VRAM. You can actually watch as the clutter appears or disappears, one album cover at a time. Less than two seconds doesn't sound very long, but you'd be surprised how little it takes to make you feel like you're "waiting for the computer", especially when simply moving from one application to the next, hiding or showing windows as you go. Toggling window visibility should be instant, and I'm interested to know exactly what is causing the lag.

Disk performance

It's a sad fact of life that most slow operations during everyday use of a dual G5 are I/O bound. Disk performance is what's keeping applications from launching instantly or files and folders from being copied without any tiresome progress bars. And when the virtual memory system starts thrashing, almost every operation suddenly becomes gated by the speed of your disk.

Mac OS X has addressed this problem in a few ways, historically. The easiest solution is to simply do less disk I/O. Application launching performance was greatly improved in earlier OS X releases by reducing the number of frameworks that are read from the disk during the launch process. The second solution is caching. Mac OS X has always been aggressive about using any available RAM as a file cache. Panther goes a few step further with two new features: automatic file defragmentation and hotfile clustering.

A file is fragmented when the data it contains is spread over the disk instead of being contained in a single, contiguous set of disk blocks. Since moving the disk head from one location to another is one of the slowest operations possible in a hard drive, fragmented files take a disproportionately long time to read. It is difficult to avoid fragmentation entirely, especially for files that grow slowly or without bound. Defragmentation collects the data from a fragmented file and moves it to a contiguous region of free space on the disk (assuming there is one large enough).

Under certain circumstances, Panther will defragment files automatically. You can read the thread in Macintoshian Achaia for all the gory details, but the short answer is that fragmented files less than 20MB large on journaled HFS+ disks are defragmented automatically in Panther when they are opened, whether for reading or for writing.

This initially strikes me as a slightly wrong-headed optimization. First, it seems odd that up to 20MB of data could be written to the disk as a result of merely opening a file (note: not actually reading or writing any data either, just opening). Second, if fragmentation is such an issue on HFS+ disks, a better solution is to improve the allocation policy or, better yet, replace HFS+ with a better file system (which Apple is doing anyway as part of its filesystem metadata enhancement project...right? Right?)

Nevertheless, I am more than willing to give Apple's HFS+ developers the benefit of the doubt and assume that this optimization was created as a result of performance profiling, and was tested and shown to provide a net performance improvement in typical usage.

Hotfile clustering, which is also detailed in the forum thread, is another optimization that I instinctively view as premature. Panther tracks frequently accessed files and slowly migrates them to a "fast" portion of the disk. This only happens on the boot disk, and there are constraints on the number and size of the files that are eligible. As a side-effect, transferring files to the hotfile area also defragments them.

It seems to me that this optimization tries to out-smart the normal file caching mechanism. But as with the automatic defragmentation, I'm willing to trust that this change has proved itself in testing. I can imagine that it does actually play well with normal disk caching, since presumably all of the very frequently accessed files will be in a conveniently cacheable contiguous cluster (say that three times fast) in the hotfile area.

The proof is in the pudding: Panther thrashes less than Jaguar on the same hardware in my experience. Admittedly, this could be attributed to many things, not the least of which is the fact that this is a freshly installed OS. But remember that I did a normal "upgrade" install rather than an "erase and install", so I'd like to think that these two new features really are at least partially responsible for the decreased disk activity.

Here's one final anecdote about Panther's file caching performance. I had to extract a few icons for this article from my Jaguar installation CDs because I'd neglected to save them before upgrading. They were stored inside a large (over 100MB) compressed archive on the CD. I used the command-line pax program to decompress the archive on the fly and extract the files. After I had extracted the first icon, I noticed that the CD had stopped spinning in the drive (this change is very audible on a G5). I then proceeded to extract the rest of the files from that same archive, and the CD never spun up again. Now that's some tasty disk caching.

Performance summary

It's hard not to like an OS upgrade that makes your computer faster. On both the lowly G3/400 and the mighty dual G5 (which started its life running Jaguar), upgrading to Panther provided an immediate and noticeable performance improvement. What more is there to say? Panther's performance lives up to its intimidating branding.

John Siracusa / John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer.