Hopes and Dreams for the Leopard Finder
September 20th, 2007Just 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.
Print This Post
From what I’ve read, I think that you’ll see great improvements in that regard. However, remember, it’s not the Finder itself that is screwed up in Tiger and previous versions (well, not the only thing, anyway). It’s the technology beneath. The multi-threading and scheduling, networking layer, IO layer. All conspire to make this a problem. If you notice that if you try a Finder replacement, like PathFinder, you won’t get much improvement either.
Read this page about leopard:
http://www.apple.com/macosx/leopard/technology/unix.html
Specifically, read the paragraphs about Autofs, Multi-core optimized and streaming I/O. They all should, at least theoretically, help the performance problem with the Finder.
I also read somewhere that I can find now, about finer grain kernel locking and I/O related stuff in Leopard that, IF APPLIED to the new Finder, should help greatly.
Anything would be an improvement. There are very few things that OS X doesn’t do well, but multiple file copies is securely on that list.
I cant say I like the current finder at all.
there are a couple of basic things that drive me nuts. Mainly the fact that when i open finder I am always having to resize a column or the windows in general. I use pathfinder mostly because when it opens I don’t have to fiddle at all. Someone told me a little trick so finder remembers it’s column widths and other dimensions. I click and drag to the size I like with the Option key held down. Problem is after you reboot it looses this and I have to do it again. Completely dumb.
No other file manager needs me to do this all the time. Frankly Windows file manager kicks Finders butt
I’m in agreement. The network issues. The file copy issues. Windows not remembering settings are all a nightmare for me.
But one thing that gets under my skin are the windows seem to take up an incredible amount of space. I would like to see the left side bar become detached and anchored on the left side of the screen and be available all the time. But windows would have to recognized that it’s there so they don’t fall behind it.
Multiple file copies is a MUST. Remember that old utility called CopyDoubler that used to do this under OS 9? How about a tabbed finder already? I think we talked about all of this on a past Tuesday Night Tech show, but none of these features seem to be featured in Leopard. What gives?!
That’s a great idea, re: detach the left sidebar and put it on the left side of the screen. there’s zero utility to having that sidebar replicated in every open Finder window. It’s basically the same logic that’s behind the single menu bar at the top of the screen — you can’t use more than one menu bar at a time, so why waste the screen space?
Great idea!
True! The most annoying thing about OS X is the Finder’s pathetic network handling. If there’s a mounted volume with Apple Share or a Samba and the network goes down (e.g. wireless) you get served. The retarded Finder will try to reconnect the volume for 10 minutes (I’ve checked in the system.log), even the shutdown process will stop. Or coming out from sleep at another place after having a wireless connection at the previous one: sometimes 1-2 minutes beachball. I developed a habit to turn Airport off on my MBP before sleep to avoid these things. Pathetic.
Ah, yes, CopyDoubler. That was one of my favorites from the “old times.” I particularly liked its Smart Replace feature, and wonder why Apple hasn’t quite mastered that.
Peace,
Gene
I’m no programmer, but I’ve heard that the Finder is still a Carbon application in a Cocoa wrapper. Carbon applications are not modern API’s that can give the power, flexibility and speed that a Cocoa API has. Carbon API’s were designed 10-12 years ago to be a transition from the old Mac operating system and they carry forward many workarounds necessitated by primitive, slow and obsolete hardware. The Carbon API’s were not designed to be multitasking and it can get confused when you try to do too many things at once.
I know that Carbon API’s have been integrated well into Cocoa over the years, but rather than asking for a changed Finder, you should be asking that Apple remove the last vestiges of Carbon from its OS. I understand that Quicktime is still a Carbon app.
Perhaps this change to Cocoa will occur, as the Mac migrates to 64 bit software. The move to Intel was good for us by removing the Classic programs which were 20 years old. Apple could not change the Finder until the last of the Mac OS 9 software was removed. Perhaps, it can do so now.
“Carbon applications are not modern API’s that can give the power, flexibility and speed that a Cocoa API has”
Please stop repeating this nonsense. Cocoa is simply a way to make programming easier and quicker to do. It does not make faster applications, rather the opposite.
The Finder is the most contentious software issue between Apple and their developers and users. Many reasons for that disharmony listed in this forum – everything from the UI design to lack of true multi threading – are unfortunately nothing new.
Personally, I find it appalling that after several years of OSX upgrades they have failed to address a key part of the OS for so long. It really does make you wonder what software development is like within Apple. So while many of us laughed at Microsoft’s inability to deliver some of the promises they made with Vista, I wouldn’t say Apples current Finder is anything to crow about. Unless you count adding a sidebar.
I’ll reserve judgment on the iTunes – I mean, Leopard Finder, until I’m using it. Until then I’ve been using PathFinder for the past few years and for me it smokes the current OSX Finder. And I’m with Gene – the Open and Save dialogue boxes need a serious overhaul. Hey – maybe that’s another ‘Top Secret’ feature we’ve yet to see?
It’s strange, Zaphod, I’ve heard differently from experts in the field. That the Carbon API’s are fine for many applications, but that they aren’t Critical Path API’s like for a Finder. I’ve heard that Cocoa makes building applications easier. But, what about the quality of the Carbon API’s? Carbon was cobbled together by taking out 70% from the old Mac OS that could not use protected memory, controlled multi tasking and reentrant programing. I understand that Apple has been working on the Carbon API’s over the last ten years, but that Apple only finalized the Cocoa API’s three to four years ago.
Again, I have no dog in this fight– just trying to understand.
So, what is it that causes the Finder to screw up so badly? The behavior that Gene Steinberg speaks of is not what I would expect of multi-tasking, multithreading API’s.
If the Finder is lacking in some respects, Carbon isn’t the culprit. The Mac UI APIs are generally not thread-safe: the Cocoa UI classes are not any more thread-safe than the Carbon UI APIs AFAIK. However, that’s not really a big issue—it’s still possible to write a program that does file copies and server connections multithreaded without threadsafe UI APIs. For file copies the Finder does do that already (not so sure about server access—hanging when servers go away is a bugbear).
If you do a big file copy and find that app launching is slow, I kind of doubt that that is the Finder’s fault—the Finder doesn’t launch apps beyond initiating the launch. The issue would be more to do with contention for disk access between the dynamic linker and the file-copy. Maybe it’s a scheduling issue. Have those complaining about this kind of performance tried doing the same copy with, say, rsync? If the Finder is slower for the same copy, then by all means bitch about the Finder, but it still won’t be Carbon’s fault; it would be a design issue in the file copy engine. Speaking for myself, the performance of the Finder is not a big problem for me (other than the server-gone hanging). It’s things like the old reliable spatial nature that I still miss; and popup folders.
Anyway, Carbon: It is neither “cobbled together”, nor a stop-gap transitional API. I think this meme about Carbon being crufty is something that has sprung up out of a desire to have something to point fingers at and blame for any old performance or cosmetic issues that have nothing to do with APIs. Carbon is a perfectly nice and really quite clean API, and absolutely beautiful compared to Win32 (while at the same time being conveniently architecturally very similar, which is why I doubt you’ll ever see a Cocoa Photoshop or Filemaker. Carbon is very important for cross-platform applications). Yes it takes more work to do things in Carbon, but by the same token, if you have to roll your own solution for some things, you might well come up with a better-performing design that if you just lazily used the Cocoa building blocks.
Disclosure: I’m an old-school Mac developer with a substantial codebase that uses Carbon (no, nothing to do with any apps named above). I will never be “transitioning” this codebase to Cocoa (which is not just a different API but a different _language_) because it would gain absolutely nothing, and would likely cost me a little bit of performance and would certainly cost all of my portability. Hence my objection to unfounded calls for the death of Carbon.
As I said, Zaphod, I’m not a programmer. I’m interested in the Mac and I’m a “Big Picture” kind of guy. This means that I listen to people talk in plenty of areas where I have no active concern. I tend to look for trends to see if they are broken.
The long term trend is for Apple to return to developments that had started in NeXTstep and Openstep. I believe that the NeXT engineers who took over Apple when Steve Jobs returned resented having to abandon Rhapsody and embracing Carbon in Mac OSX. They have integrated Carbon well into the programming envelop, but I see signs that Apple is starting to move away from Carbon.
Apple seems to consider it “Legacy” programming and it has shown no hesitancy to abandon legacy software or hardware. I don’t imagine that there will be any announcements: just no new developments for Carbon.
Carbon will be consigned to 32 bit applications and the Mac runs well in 32 and 64 bit. We will wake up one day to find that everything on the Mac will be 64 bit and it will all be in Cocoa. By that time, there will be another migration to leave behind the Carbon API’s, but I don’t see that happening for many years. Almost all of Apple’s hardware base, at its current growth rates, will be 64 bit Intel in five years, so who will care if Carbon is left behind? You? Sure. But, anyone else?
May I suggest that you read the website of a Cocoa programmer discussing the impact of Objective-C 2.0 and a new version of Xcode which will be supplied in Leopard.
http://theocacao.com/document.page/496
Programming in Carbon will be more time consuming and thus costly than with Cocoa because there are fewer features. There will be a gentle pressure on you to abandon it. Carbon has no future at Apple; the future is 64 bit.
My point is that the Finder is in Carbon and it needed to be so as long as there are many PowerPC Mac’s. There was no point to rework the finder in what Apple considers to be obsolete API’s. But Apple isn’t ready to go to a Cocoa Finder yet. In 10.5 Leopard? Not so I have heard. 10.6 in a few years? Perhaps.
Yeah, Apple needs to stop focusing on candy and touchscreens for a while and Just Fix The Bloody Finder!(TM). The stupid thing hangs because it’s looking for a phantom printer or network device, for heaven’s sake. Does it not understand that notebook computers move?
Also, why is it that browsing a large gallery of images in Microsoft Windows XP is so much faster and less painful than doing the same in Apple OS X? I ran a competition once, where I put my Windows PC (single Pentium 2.66GHz, 2GB RAM) and Mac (dual 1.8GHz G5, 2GB RAM) side by side and then opened a folder (in thumbnail view) with the same contents of about 200 high res photos. The Windows PC was sitting by the roadside whistling and checking its fingernails while the Mac is still huffing and puffing about 2 miles away.
The current Finder performance always manages to piss me off for some reason.
Are you browsing the images in the Finder or iPhoto?
Just curious.
Peace,
Gene
“so who will care if Carbon is left behind? You? Sure. But, anyone else?”
Adobe? Filemaker? Quark? Microsoft? Everyone with an interest in cross-platform software. Everyone who relies on software that’s been around for more than about 5 years. Anyone who wants to write software that’s not locked-into the Mac. Evidently you don’t care about any of these, but a lot of people do.
Looks like improvements to Finder is worth the price of upgrade. 🙂
Zaphod, I’m talking about where Apple will be in five to ten years. Apple, ten years ago, was beleaguered; now Dell is. There will be enormous hardware changes coming– paradigm shifts, even. I don’t really know where Apple is going with Objective-C 2.0 since it doesn’t seem to work with Mac OSX 10.4 Tiger. Apple seems to be obsoleting any previous software, so why not with its Finder, too.
If Adobe, Filemaker, Quark or Microsoft want to be on future Macintoshes they will need to program in Xcode and that will push them toward Objective-C 2.0 and away from Carbon. It will be a gentle push, but it will be evident.
I don’t have to care about those above people; they need to decide what camp they belong in. The old paradigms, and the marketing strategies therein, are fading. I’m trying to see the new ones. Microsoft’s dominance is at jeopardy, not just from Apple, but embedded Linux. Windows is getting very old, very fast. Apple is likely to steal away Microsoft’s high end consumer market while embedded Linux steals away the bottom enterprise market. Why does a cash register have to run Windows?
Apple seems to be ignoring cross-platform software developers. BootCamp encourages that. Why be cross platform when you can have concurrent OS’s? Virtualization hardware from Intel is pushing in that direction, too. Is this a bug or a feature? Or does Apple have cards up its sleeve? I can’t tell.
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.
Louis: I don’t dispute that Cocoa is the future (not to mention the present) of most Mac development, but as long as the Mac is a minority platform, then cross-platform software does matter to a lot of people (virtualised Windows is an expensive last resort). I’m guessing Photoshop will still be around in 5-10 years, and Adobe have their own framework for x-plat development and they would be crazy to throw that away and double their workload. My only point really is that the irrational, quasi-religious belief that Cocoa is a silver bullet for performance is just plain wrong. Making software easier to write does not make it faster. Usually the opposite is true. Take a look at Pages 3 for an example. Rewriting the Finder in Cocoa won’t make it faster and it won’t make it better. Redesigning/rearchitecting it could make it better, but that’s not connected to the API you use. When a program deviates so far from the application model that Cocoa is designed for (as the Finder does), then it’s all new code anyway.
Some folks feel Apple has already done that 🙂
Peace,
Gene
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.
“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
“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.
hmmm…… flash drives I assume wont have these issues then?
Interesting read, makes me want to buy a Macpro with 3 drives.
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.