The Slowness of Archive Utility
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.
It took just 0.013 seconds with gzip Terminal.
Update (2016-12-09): Nick Heer:
[…] many archives will take less than a second to expand using the Terminal. Those files should, ideally, be unarchived in place, without opening an additional window.
4 Comments RSS · Twitter
The author is assuming that Active Utility is nothing more than a GUI wrapper around the command line tools. This is not true. The Archive Utility is to command line utilities what the Finder is to command line utilities. For example, instead of just extracting a file, it will create a temporary directory, extract a file to that temporary directory, then rename them all and put them into place. Any NSDocument-based app does a similar kind of file/folder dance every time you save a file. In short, it is horribly inefficient at the file system level.
I wrote an app once that inserted itself as a localhost server that the Mac networking client would connect to. One of my most demanding tests was running Archive Utility through this interface. It doesn't just extract files, it really punishes the file system.
@John I realize that the file/folder dance is inefficient, but half a second per file still seems excessive. I would bet that much of the slowness is in the GUI.
Have you looked at the video Rob has posted on his site? It looks to me as if the slowness comes from the fact that each extraction is only triggered once its animation is finished. So, instead of simply starting 25 extractions in a single thread, processing them without pause in sequence, Archive Util picks one after the other, starts their animations, and only when the anim is done, starts the extraction. And the animations are all happening in the main thread, probably, all queued, so that each has to finished before the next can be triggered.
Such a procedure would be easier to implement, too, rather than updating the animations according to the current state of the all-processing background thread.
I too often see animations that are blocking further processing needlessly, especially on the iPhone, where a running animation prevents you from tapping controls, even if they should be decoupled. It's lazy programming. Something most devs are probably not even aware of.
@Thomas I think you’re right. I see the same issue every month when I download my iTunes Connect reports.
