
The Finder’s GUI tax can be very expensive - hyperpape
http://robservatory.com/the-finders-gui-tax-can-be-very-expensive/
======
patio11
I wonder whether this is not an example of a UI interaction which is slow on
purpose, to emphasize how much work the OS is doing for you.

TaxAct and TurboTax, for example, both operate on (in the typical case)
kilobyte scale data requiring trivial math. They also make both saving the
data and calculating taxes take 5+ wall-clock seconds when they actually
require milliseconds and nanoseconds respectively. This is largely because
(non-technical) users don't trust your computer did the math right if the
answer comes back instantly. (I also suspect there is an element of "Wait if
it is so easy to calculate my taxes _why am I paying you to do that_.")

~~~
radley
No, it's about showing it long enough so you know what the dialog is and what
it's doing.

If a dialog popped up for the brief amount of time it actually takes to unzip,
it might freak out users: "huh? WTF was that??"

~~~
kalleboo
The Finder already handles this differently for file copy operations - you
don't get a file copy progress dialog if it takes less time than you need to
react (just an audio confirmation). It seems like Archive Utility didn't get
that extra attention though.

~~~
radley
Maybe it's a minor security feature. Unzipping something in the background
might be something they want to always call attention to.

------
TheAceOfHearts
If someone is looking for an alternative with a GUI, I use The Unarchiver [0]
and I'm generally happy with it. I don't usually have to expand lots of small
files like the OP, so I don't know how it compares with that task.

[0] [http://unarchiver.c3.cx/unarchiver](http://unarchiver.c3.cx/unarchiver)

~~~
curun1r
Seconded. The Unarchiver is always one of the first things I install on a new
Mac.

The same author is also responsible for another program, Xee, which is a
great, no nonsense image viewer. The 3.x version costs a few bucks, but the
last 2.x version can still be downloaded for free.

------
cesarb
> a window with a single progress bar for the entire task would be OK, but
> would still slow operations down.

There's a simple way to do a visual progress bar with almost zero slowdown:
run the task in a separate thread from the progress bar, and update the
progress through lock-free shared variables. Make the progress bar read the
shared variables only a couple of times per second, sleeping between its
updates.

~~~
fredsir
It's not only the communication between the task and the GUI that is slowing
things down (if it is at all, which I doubt). Even more, I think, it's the
fact that macOS, the OS in question, has some conventions for windows,
controls and so forth, one being that it takes X seconds for the window to
appear and X seconds for it to disappear. If it was being shown and hidden
again as fast as the task starts and finishes, it would be just be a flicker
on the screen, which would confuse the user. It also doesn't make sense to
spend a second to show a window, if the progress bar it embeds has completed
before the second has elapsed, so there has to be a delay there, and so forth.
The task is so quick it can really not be presented to the user without the
presentation being slower than the actual task.

I think it comes down to good UI+UX, which in this particular case becomes bad
UI+UX.

~~~
userbinator
_If it was being shown and hidden again as fast as the task starts and
finishes, it would be just be a flicker on the screen, which would confuse the
user._

Maybe the really inexperienced users, but it makes sense that something which
happens quickly, will mean a window that also appears and disappears quickly.
This is why Windows has options to disable animations and other effects, and
everything does feel noticeably more responsive when they are disabled ---
windows and menus appear and disappear _instantly_.

------
advisedwang
How did they not title this "Finders Fee"

~~~
goldenkek
Hah.

------
headcanon
I've encountered this in command-line programs as well. Print statements take
a non-zero amount of time and depending on the language, can be quite slow, so
for an otherwise-fast operation in a loop, if it prints a line every time then
it can contribute significantly to the overall speed of the program. Removing
the print statements in some cases can speed up the code by an order of
magnitude.

~~~
dijit
quiet reminder that writing to file descriptors is blocking.

STDERR and STDOUT are file descriptors.

~~~
thaumasiotes
Maybe so, but, as pointed out elsewhere in the thread, printing to stdout is
much, much, much, much slower than printing to a file. The fact that stdout is
a file descriptor can only explain a vanishingly small quantity of the time
cost of using it.

~~~
majewsky
> printing to stdout is much, much, much, much slower than printing to a file

False dichotomy. stdout can very well be a file. What you mean is that
printing to a _terminal_ is slower than to a file.

~~~
thaumasiotes
True enough.

------
bluedino
Reminds of of this Raymond Chen post:

[https://blogs.msdn.microsoft.com/oldnewthing/20060220-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20060220-00/?p=32233)

A Windows program ran faster if you clicked and held the mouse button on the
title bar (as if you were going to move the window) because it would stop the
window from re-drawing itself, making whatever loop it was running (and
constantly updating the GUI) go faster.

------
Normal_gaussian
If we are assuming the underlying expansion is as efficient then the cost
comes either in the boilerplate or mistakes made when parallelising. In the
case of the boilerplate the solution would be embedding some more of the
linked code and reducing IPC/other unnecessary bottlenecks. However I suspect
the error is in the parallelisation, which is not surprising, especially as
the authors likely optimised and tested for large, not small, files.

As it is, removing the GUI is perhaps the worst thing you could do to the
user. Closely followed by inducing epilepsy with that ridiculous expanding
dialog.

------
hughw
"Finder (nee Archive Utility) should just execute the task without any visual
feedback" \-- no.

~~~
hbosch
I agree there should be visual feedback, but maybe more of a compromise. E.g.
bundle all unzip tasks into 1 single progress bar and rotate text strings for
informing which task is underway.

The "dancing" modal is quite ridiculous.

~~~
wruza
If operation takes more than human's average reaction time, progress should be
shown. Usually 250ms. Jef Raskin and others wrote a bookshelf about that a
decade ago, but I still see strange solutions everywhere.

~~~
aidenn0
In this case it's showing a 24 progress bars each for an item that takes less
than 1ms.

------
jcoffland
Windows explorer unzip is even worse. Recently in a VM I tried unzipping boost
1.62.0 using explorer in Windows 10. It said it would take over 3 hours. The
same file was decompressed on the command line in about a minute using 7zip on
the same VM.

~~~
Someone
Windows also always unzips to a fixed scratch directory before creating the
real files.

That scratch directory is %TMP% or %TEMP%, I think, but it definitely always
is on the same disk, typically C:

If you unzip files to another disk than where that directory lives, it unzips
to its scratch directory, then _copies_ the extracted files to their
destination, and finally deletes the scratch files.

That's bad in itself, but doubly so if the disk where it unpacks doesn't have
room for the unzipped files.

Mac OS had a system call "Give me the temp directory on this disk"
(FindFolder) that made it possible to extract to a temp directory and then
_move_ the result to the destination. That call made it into Carbon. I don't
think macOS still has it, but it seems UnArchiver does the right thing,
anyways.

~~~
aidenn0
Internet explorer did the same thing with downloads; I discovered this when I
had a 1GB C: drive and a 6GB D: drive and tried to download something that was
too large to fit on the C: drive.

------
michaelbuckbee
It's fixed now, but for a while it was significantly (20 to 40%) faster to
install npm without the progress bar.

[https://github.com/npm/npm/issues/11283](https://github.com/npm/npm/issues/11283)

~~~
couchand
Just to clarify, that's 'npm install' not 'install npm'.

------
DominoTree
The window animations in Mac OS itself can make things feel very sluggish as
well, although the velocity-based ones seem better with Sierra.

------
ythn
There's a point where printing progress is actually a huge bottleneck to
performance. Try it out in python. Make a for loop that loops a million times
and prints "Hello". Run the program once normally, and a second time piping
the output to a file. You'll find the first one takes 15 seconds, while the
second one is near instantaneous.

~~~
goldenkek
This is a false equivalence. As long as the progress is set correctly via
messaging (queue) to an alternate UI thread, the time lost will be under a
millsecond. The naive print loop you provide is obviously IO bound and print
is a blocking IO call. Use an async print IO and youll have much better
performance. Narf!!

------
__jal
They should make the UI idiom feeding your file a mushroom and then double the
icon size on completion.

~~~
robotmlg
only if they want to get sued by Nintendo...

~~~
headcanon
Nintendo got it from Alice in Wonderland, so perhaps prior art?

------
somanychoices
The rationalizations are kind of silly... oh no, the uninformed users might
otherwise do or think this or that; actually, this is shit workmanship, that
is all it is, and it's up to the people who have the faintest clue to point at
it an laugh _until it becomes better workmanship_. If you use energy you
should use attacking it on defending it, you're now part of it.

------
rebuilder
Even worse, IMO, is that the default behaviour for Archive Utility is to just
unpack the contents of a zip file in a directory under which it's found.
Sometimes I just want one file out of a huge zip... Actually, quite often I
want to see what's in a zip before uncompressing.

------
castratikron
Isn't there some disk caching going on here? Surely the OS is not writing
directly to disk immediately after gunzipping. I don't think that's enough to
explain the large difference, though.

------
whywhywhywhy
Great example of someone justifying engineer driven design over user driven
design. Not understanding at all why it was made that way in the first place.

------
stefs
"... slow, it’s the GUI interface to the computer ..."

he ... he wrote GUI interface. heh.

------
module0000
Just want to add, `unzip` from your terminal window can be used as well. If
opening those gz's every month is a pain, you could handle it with something
like: `unzip -r my_stuff_{1..99}.zip`

~~~
proaralyst
The files in the article aren't zips, they're individually compressed files.
Thus, unzip won't work.

------
vortico
This will be sort of bluntly stated, but I challenge anyone to show me an
example of where animation is a usability improvement over no animation at
all. I understand how it may be visually pleasing, but I work on computers,
not enjoy it as an art form. I do some UI design too and don't remember the
last time I added animation. Can anyone find an exception?

~~~
pvg
Most transition effects where things are added or removed from a group of
objects - without the visual cue, this can happen so quickly it's hard to see
where the removal or addition happened. The tab bar in your browser is a good
example.

