Skip to content

expand

Quickly expand compressed files in Finder

In this post, I lamented on the incredible slowdown seen when expanding many compressed files in Finder. To save a trip back to that article, here's the tldr; version:

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

With a bit of work, though, you can harness the power of Unix in Finder, and get both the GUI and the speed when expanding files. There are many ways to do this, including third-party apps such as The Unarchiver. You could also write an Automator Service to do the work for you. But I chose to write a Keyboard Maestro macro, because I could make the macro a menu bar option that only shows when Finder is frontmost:

As seen, I actually have two expanders, one that expands just the Apple sales reports mentioned in my original post, and the other that will handle any mix of compressed files. (Yes, the 'all files' macro could also handle the Apple sales reports, but because of how it has to run for multiple file types, it's marginally slower than the dedicated macro.)

These macros both work in the same way—they call on Unix apps to do the expansion, bypassing Apple's slow GUI expander (which is called Archive Utility). If you're curious how they work, and/or would like to download them for your own use, keep reading.

[continue reading…]



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 filesFinder:
12.8 seconds
Terminal:
.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.