Hacker News Reader

Comment by pvg | Hacker News Reader

That's highly unlikely. Archive Utility is just slow.

I think you're probably right. I'd imagine that most of the code in Archive Utility.app is very old, and there's very little business reason to spend any engineering time on improving it beyond doing just enough work to make sure it works with API changes for later OS releases.

There are third party GUI compression utilities that are faster that you'd find if you actually care about how long it takes to decompress your archives, and the CLI utilities are all there out of the box for people who don't need a GUI.

If it's really old, shouldn't it be faster as it would've been designed to perform adequately on way slower CPUs? ;)

No? There are a dozen trivial reasons you can easily think of why that wouldn't be the case.

Newer means different. Older means different. Different CPU meet differently optimized code meet different cocoa framework. Narf!

It's highly unlikely that it's 1000 times slower than the command line utility to decompress, with which they share the same libs anyway...

It isn't because they don't do anywhere close to the same thing. Watch the video:

http://robservatory.com/postimages/unzipping/finder_v_termin...

Where do you think the people who wrote the thing that happens on the left inserted a gratuitous sleep?

For each file, a split second to animate the apparition of the window (or the increase of the existing window), another split second to show the empty progress bar, a millisecond to fork the decompression process, a couple of frames at 60 Hz to animate it being filled, and another split second to animate the disappearance of the window (or the decrease of the existing window).

None of these are deliberate idling to give the impression of work which is what the original comment was about.

Huh? ALL of these are deliberate idle time (idle as in "not spend in actually decompressing) to give the impression of work ...

By that (deeply silly) logic, 'having a GUI' is 'deliberate idle time'.

No. You'll notice that your browser doesn't sequentially wait for each character to show up on the screen before rendering the next character.

The obvious thing to have done would be to have a single progress bar for all decompression operations requested in a single UI action. Darwin has had a process scheduler for some time now; they can be expected to make good use of it.

It is infuriating to be waiting for animations to end for literally 12 seconds.

Again, this has absolutely nothing to do with the original and inaccurate idea that Archive Utility waits around doing nothing on purpose to give you the impression it's doing something while it's doing nothing. It just means AU is implemented in a way that is slow and inefficient. Which is what I said so hey, we agree!

obviously when they show the notification for each completed unit?

What is highly unlikely about that? That seems more plausible than, zlib is magically 1000x slower when used by Archive Utility.

What seems more likely to me is that the "decompressing a large number of small archives" task is so rare that Apple hasn't optimised it. More likely than "Apple added an arbitrary delay to make the interface more satisfying."

It's unlikely it's on purpose. It makes sense in something like tax software you use once a year. It makes no sense at all when doing a bunch of i/o bound operations which are already potentially slow.

Reply on news.ycombinator.com