Visit the all-new Tech Night Owl Store
  • Explore the magic and the mystery!
  • The Tech Night Owl's Home Page
  • Visit the all-new Tech Night Owl Store
    Namecheap.com





  • Hopes and Dreams for the Leopard Finder

    September 20th, 2007

    Just the other day, while recording an interview with Mac author and commentator Kirk McElhearn, we both ruminated about the fate of the Mac OS X Finder in Leopard. I think most of you agree with us that the present Finder is severely broken, and has been from the first.

    No, I’m not talking about the basic interface, because I think that’s pretty much in good shape. I’ve always found the column view a convenient way to check your stuff and drill down into deeply-nested menus. There are times, of course, when I prefer list view to reorder file display and such, but the basic layout gets the job done.

    We could, of course, talk of ways that things might improve, particularly when it comes to the Open and Save dialog boxes, where features that were pioneered years ago in such products as Default Folder and Super Boomerang, such as automatic rebounding to the last opened file, are still missing in action.

    It’s not that such tweaks represent an insurmountable problem for Mac OS X, since Default Folder has remained compatible with each operating system upgrade all these years. However, Apple’s online documentation for Leopard fails to mention any such enhancements, so I’ll assume that, aside from taking on some of the more distinct elements of the Leopard interface, the Open and Save dialogs will remain largely untouched. Sad, but true. But at least the publisher of Default Folder can continue to sell the product without competition from Apple. Our kudos to programmer Jon Gotow for his great work in making Default Folder such an indispensable tool.

    Maybe he deserves a job at Apple, or maybe that’s the farthest thing from his mind.

    As to the Finder itself, the prospect of grafting cover flow from iTunes affects me hardly at all. It’s neat to look at if eye-candy is your thing. But I prefer to see lists of the files I want to open, not pretty pictures that will simply put the brakes on my Finder navigation process. But that’s a viewing scheme that is optional, so you can do what you want, and if you like the effect, then maybe Apple was right to include it. Of course, once I have the chance to really use Leopard, maybe I’ll change my tune, but I doubt it.

    My real concerns for the Finder are far more mundane. I want it to work efficiently, without bogging down. Now that may not seem to be such a demanding request, but when you look at every single version of the Mac OS X Finder, you’re apt to think it’s an impossible accomplishment. Sure, it’s gotten a little better over the years, but when you see it in action in a quad-core Power Mac G5 or Mac Pro — let’s not worry about the eight-core version of the latter — you will be astounded how bad things can be.

    Consider a very simple action, which is to copy the same 10GB folder to two other drives for backup. This is something I do regularly with my stash of audio interview files. And it doesn’t matter if the drives are internal or external, but let’s just say they are real fast mechanisms

    The first symptom you’ll observe is that the Finder has apparently been struck by a severe case of flu, for it becomes extremely sluggish. You try to open an application during this file copying process, and the launch sequence seems to take minutes, rather than seconds.

    If you have the temerity to try to open a Finder window and look over a few things, watch out for the spinning beach ball, because it can get to be mighty frustrating.

    Now consider network access. Apple touts its cross-platform capabilities, but watch what happens when the file share falls off the network for any reason. It doesn’t have to be a crash. Say you’re sharing files with your MacBook and the note-book drifts into sleep mode. The Finder will take its sweet time figuring that out and then some. During that period, you may think the Mac that’s connected to that MacBook has, itself, fallen asleep or perhaps crashed till things clear up, as they do eventually.

    Admittedly, a MacIntel seems to be a better home for Mac OS X, and the slowdown isn’t so severe. In fact, my dual-core MacBook Pro with 2GB of RAM outshines the G5 quad, with 4GB of RAM, in that regard. But the PowerPC is history, so I suppose I shouldn’t fret over that. An Intel-based desktop is on my shopping list, and one of these days, I’ll act.

    But I’m not saying anything here that Apple doesn’t know. Indeed, I have little doubt that Apple wants the Finder to, once again, become the showpiece of the Mac user experience, which means that speedy performance and efficient multithreading should be a given.

    Will it happen in Leopard? I can’t make any predictions, nor do I want to know what’s going on with the beta process, since that’s protected by Apple’s confidentiality agreements. Besides, any experience one has with prerelease software, good or bad, doesn’t always follow completely through to the final release.

    Let’s just say that I’m extremely optimistic that Apple gets it, and, further, that we will see many of our hopes realized when Leopard is released.



    Share
    | Print This Article Print This Article

    27 Responses to “Hopes and Dreams for the Leopard Finder”

    1. The tea-leaves I’m reading say that Apple is developing advances in its operating system that will leave Microsoft in the dust. Apple has had a tendency to patiently lay the groundwork for years before the implications are driven home. I’m getting hints of implications that seem to be going over your head. But again, I have no dog in this fight.

      Some folks feel Apple has already done that 🙂

      Peace,
      Gene

    2. Louis Wheeler says:

      Zaphod, I was giving a reason for why Apple has failed to do what seems obvious to many Mac users– to fix the Finder. Why hasn’t Apple produced a better Carbon Finder? Apple has limited resources. It may not think it necessary to devote the programming time to something with a short life expectancy. Remember how long Mac users have complained about the inconsistent User Interface between various applications. A unified User Interface is only coming in Leopard. I’ve been hearing this complaint for six years and more.

      I believe that Apple will be converting to an entirely Cocoa OS, but there may be reasons why this was impractical. Perhaps, it still is. So, If the Finder needs to be converted to Cocoa then it needs to be Redesigned/ re-architected to reduce wait states. Is the current Finder multithreading/ Multitasking? I’d guess not. Will it take advantage of the two to eight processors that will be common in even laptops in ten years? Not likely The problem here with the Finder is that it hangs. A Cocoa Finder may be slower but it doesn’t hang. Cocoa may be slowet but multi threading may make up for that.

      Apple seems to be forging ahead with 64 bit Objective-C 2.0. In the process it is engineering new technologies such as Core Animation. I get the feeling that there are many new technologies that will be designed into the Cocoa OS. These will leave behind those companies who choose not to abandon Carbon. If Photoshop and other companies do not use Xcode and objective-C 2.0 then they will be Quarked. If some other company doesn’t do it, Apple will. I do not believe that Apple will allow itself to be held hostage by a developer no matter how currently powerful.

      Then, there may be developments that we know nothing about. Could Xcode create cross platform applications that use Quicktime and Safari for windows? Neither Quicktime nor Safari use Microsoft Windows API’s. They could not because Microsoft has a history of sabotaging its competitors.

    3. Louis Wheeler says:

      “The tea-leaves I’m reading say that Apple is developing advances in its operating system that will leave Microsoft in the dust…

      Some folks feel Apple has already done that ”

      You know that. And I know that, but does the public? It’s not good enough for Apple to be twice as good. It has to be five to ten times as good. Apple needs the WOW factor; it needs the inexpensive factor. None of this will be easy. Fortunately, Microsoft is helping this process along.

    4. “The tea-leaves I’m reading say that Apple is developing advances in its operating system that will leave Microsoft in the dust…

      Some folks feel Apple has already done that ”

      You know that. And I know that, but does the public? It’s not good enough for Apple to be twice as good. It has to be five to ten times as good. Apple needs the WOW factor; it needs the inexpensive factor. None of this will be easy. Fortunately, Microsoft is helping this process along.

      And probably not realizing it. 😀

      Peace,
      Gene

    5. Julian Berdych says:

      “Consider a very simple action, which is to copy the same 10GB folder to two other drives for backup. […] The first symptom you’ll observe is that the Finder has apparently been struck by a severe case of flu, for it becomes extremely sluggish. You try to open an application during this file copying process, and the launch sequence seems to take minutes, rather than seconds.”

      The basic problem here is contention for the disk head. When you start a 10GB file copy, the Finder queues up dozens of I/O requests for the various chunks of the file, and those chunks are usually relatively close to each other on the disk. The disk head simply “walks” the drive surface and chugs out data at close to the theoretical maximum performance, especially if the source file is on one drive and the destination file is on another.

      Launching an application is simply an exercise in page faulting, that is, bringing the necessary application code and libraries from disk into RAM. It’s a basic Unix function, and again, dozens of I/O requests are queued to the disk driver for the various chunks of code that need to be read in from disk.

      Now herein lies the problem: it doesn’t matter if you have really fast 7200 RPM disks on a 3 GB/sec serial ATA controller (that helps ONLY if you’re doing just one thing at a time). The moment you have two competing sets of I/O requests for files on different areas of the same disk, the heads are going to go back and forth and back and forth between those areas. Every “back” and every “forth” averages 4 to 5 ms (known as “seek time”) on the very fastest 7200 SATA drives, and that drops the number of executed I/O requests from a peak of 200/second (typical of launching an application without doing anything else) down to 20-25 per second. Don’t just take my word for it; use the Activity Monitor to watch Disk Activity, and you can see the I/O rates yourself while you copy files and launch applications.

      This order-of-magnitude reduction in single-disk performance under multi-threaded situations has been known for decades and is a direct result of disk drives still being mechanical devices. If you’re complaining about it now, too bad you weren’t around 30 years ago in the days of DEC (Digital Equipment, remember PDP-11s and VAXes?) RK07 disk drives… a whopping 27 MB (yeah, 0.027 GB) in a two-platter 14-inch-diameter removable disk pack, 2400 RPM with an average seek time of 36.5 ms… and around 30 seconds to come up to speed on power-up. Disks were ten times slower (and 20,000 times less dense) back then than they are today.

      The decades-old solution to poor launch time during heavy file-I/O is really simple: put the operating system on one drive (most of the I/O will be paging and swapping), the applications on another (most of the I/O will be application paging) and your application’s data on a third drive (where most of the I/O will be application-related; e.g. copying, database access, etc.). This explains why higher-end desktops and servers always have at least two independent disk controllers and four drive bays: if you want high-performance multi-threaded disk I/O, you need to have the parallel hardware to support it.

      So kindly refrain from bashing the Finder’s disk performance when it has absolutely nothing to do it. Any computer with a single drive or a single disk controller – running any operating system – will exhibit slow multi-threaded disk I/O performance. But you should see my dual-1.25 GHz Power Mac G4 with four drives (two 80 GB plus two 320 GB) scream.

    6. shane blyth says:

      hmmm…… flash drives I assume wont have these issues then?
      Interesting read, makes me want to buy a Macpro with 3 drives.

    7. Julian Berdych says:

      True, flash drive throughput doesn’t suffer with multiple parallel accesses, but flash memory has performance issues of its own: the read-to-write throughput ratio is usually around 10:1. I can read large files off my 1 GB Kingston DataTraveler Elite at about 20 MB/sec (not exactly blazing, but pretty respectable for a USB memory key), but writing is another story: 1.27 MB/sec average. That’s because flash memory, unlike RAM or disk, must be *erased* before being written. The microcontroller found inside all USB memory keys performs block-by-block erasure on the fly, thus simulating a writeable random-access volume, but because data can’t be written while a block-erase is in progress, all current flash devices have poor write performance.

      And now you know why the (flash-based) iPod nano takes a surprisingly long time to sync a large iTunes music library.

    Leave Your Comment