The Robservatory

Robservations on everything…


The Finder’s GUI tax can be very expensive

Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the “Open ‘safe’ files after downloading’ item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).

If you work with lots of compressed files, you’re probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…

[Note: Technically, this isn’t Finder, it’s Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it’s what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it’s Finder handling the expansion. For ease of reference, I’m going to say it’s Finder doing the expansion.]

Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—”it took over 12 seconds to expand 25 tiny little archives!”—when what they really have is a horrendously slow GUI interface to a super fast task.

Just how fast is the task, if the GUI doesn’t get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you’d use this command in Terminal:

gzip -d -k *.gz

If you try this, you’ll find out it’s nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:

$ time gzip -d -k *.gz

real	0m0.013s
user	0m0.002s
sys	0m0.005s

This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…

Expand 24 .gz files Finder:
12.8 seconds
.013 seconds
Terminal is 984.6x faster than Finder

To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That’s nuts!

(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)

So it’s not the computer that’s slow, it’s the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there’s no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.

Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.

This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it’d be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here’s one way to do just that.


Add a Comment
  1. Hello Rob,
    Thx for the Post!
    The Finder GUI is horrendous in my opinion!
    Try to open a finder window from a folder with a several thousand files…… Pathetic compared with WindowsOS.
    Or the absence of color-contrast like you used to have with Finder-column items and Labelcolors.
    And how about the open&save dialog with way too small name-field.
    Let’s not forget the lack of Finder-copy options: copy-speed/copy-speed average, and verification (DS files)

    Some of those can be partly solved by using ExtraFinder, TotalFinder, DefaultFolder(not anymore)

    Thank God we’ve got these and QuickLook

    Apple doesn’t have any clue anymore! (How hard can it be?)

    The only real feature they can implement are Emoji’s and other mumbo jumbo.

    Let’s hope for the better, but the recent MacBook Pro Gate/MS Surface Studio and the lack for PRO hardware did show; Apple has lost it’s Mojo for a long time!

    1. Anymore? The Finder has been a disgrace since the advent of OS X, and probably decades longer. Only in the latest release, after YEARS of user complaints, can you finally have Finder sort correctly (with FOLDERS ON TOP of alphabetical lists). And it doesn’t work everywhere yet; they forgot about the desktop.

      The problem with “replacing” Finder is that you can’t, really. It’s still the underpinning of file dialogs. Which brings us to more defects: Ever click on a file in a subdirectory in a Save dialog to overwrite it, only to look at the file later and discover that it’s the OLD version? Then you think about it, and hey, I wasn’t asked if I wanted to overwrite the file.

      That’s because the File dialog erroneously put the file at some higher directory level from the one you clicked on.

      Then there’s the fact that Finder’s “New folder” command doesn’t create the folder WITHIN the selected one; it doesn’t even give you the option to do so if you right-click on a folder. WTF?

      And if you’re copying a bunch of files into a folder and there’s a duplicate in there already, there’s no option to skip the duplicate and continue copying. There’s only “Keep both,” “Stop,” or “Replace.”

      Then there’s the fact that Finder always shows you the dumb disclosure triangle (WTF is a triangle supposed to tell you) next to a folder, even when the folder is empty. Windows Explorer only shows the (universally understood) + sign next to folders that have stuff in them, saving you time when you’re looking for something. Sadly, after XP, Microsoft essentially ruined this feature by inexplicably hiding the + symbols unless you happen to roll the cursor into the left pane of Explorer. Yet another WTF.

      1. When copying duplicate files in OS X, at least in El Capitan, hold option and the “Keep Both” option becomes “Skip”.

  2. It’s actually not Finder that displays this but Archive Utility (as you can see in the title bar above), a separate application in /System/Library/CoreServices/Applications. It’s easy enough in the Finder’s Info window to change the default application for .gz, .zip, etc., to another option such as The Unarchiver, which is typically much faster at doing its (GUI) job.

    That said, the Finder is a mess these days and probably had its peak around 10.6; it seems incredibly under-resourced these days. (As if to spite me when I was testing this, my home folder Finder window randomly showed the preview pane, as it does several times a week. I hide it, it comes back.)

    1. The changes won’t be as dramatic, because it’s the GUI updates that are really slowing down the “lots of little files” expansions.

      However, I just tested on a 7GB zip that contained 663 files for various Keynote presentations. In Finder, it took 1;24 to expand; in Terminal, just over a minute. So it’s still faster to avoid the GUI.


    1. I chose Finder on purpose, as it’s where most users assume the problem lies—very few know that it’s actually another app doing the decoding. But when I report it to Apple (and I will), I will only mention Finder in passing, relative to the GUI slowdown seen by users when expanding in Finder.


  3. Jetbrains had a really nice solution to this problem in their IDE(s), They show the progress bar dialog (for long operations) only after 300ms. If the operation completed before that, no progress bar dialog is shown.

  4. I suspect it’s a case of “lazy programming” by putting the animation in sequence with the processing. Such as: Archive Utility (AU) gets a list of 25 files to process. It picks the first, starts the animation to add it to the progress window, and once the animation (which takes probably a 4th of a second) is finished, the unarchiving process is started. Then AU picks the next from the list and so on.

    To make this super-fast, the process would have to be changed like this: All 25 pending files are sent to a second (background) thread that processes them, without pause, in sequence. If that’s done, they may indeed finished within a fraction of a second. The main thread (which is the one updating the UI) would then have to look at how many files are current in progress or finished and then update the UI accordingly, which could lead to showing all 25 files in the window at once, and then make them all disappear again at once. That, however, is harder to program, and may also be overwhelming to watch, because if the window suddenly shows 25 items and makes them disappear again within half a second, the user may just think: What just happened, I could not follow it! Whereas the current behavior lets you guess that all the flickering means that all those 25 files get quickly progressed.

    The odd flicker could be avoided by making sure that every processed file at least stays visible in the UI for a second, even if it was running only for a tenth of it. Could still look confusing, or annoying, since the UI would show needlessly long.

    So, this “slow” behavior may be a concious choice to provide better user feedback, or / and it may just be a common case of the lazy “it works, and that’s good enough” development effort.

  5. Interesting I’ve been noticing a LOT of things on macOS are slow, in the sense of they take a beat to happen. It’s like Apple’s programmed in a momentary delay.

    For example my Mac has a super-speedy SSD, 16GB RAM, and a 2.8GHz quad-core chip. When running Windows it’s just insanely fast. Boot back into macOS and, again, it’s like walking rather than running.

Leave a Reply

The Robservatory © 2017 Built from the Frontier theme