The Finder’s GUI tax can be very expensive • Hacker News Board

Re: The Finder’s GUI tax can be very expensive

#21

Post by wruza » Thu, Dec 08, 2016, 10:51 PM UTC

hbosch wrote: post #10

hughw wrote: post #3

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

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.

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.

Re: The Finder’s GUI tax can be very expensive

#22

Post by 8ytecoder » Thu, Dec 08, 2016, 10:52 PM UTC

patio11 wrote: post #16

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 lar…

No kidding. In one of my previous companies we explicitly added a delay in our financial webapp. We saw a significant improvement in bounce rate after that.

Re: The Finder’s GUI tax can be very expensive

#23

Post by fredsir » Thu, Dec 08, 2016, 10:52 PM UTC

cesarb wrote: post #7

> 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.

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.

Re: The Finder’s GUI tax can be very expensive

#24

Post by pvg » Thu, Dec 08, 2016, 10:57 PM UTC

patio11 wrote: post #16

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 lar…

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

Re: The Finder’s GUI tax can be very expensive

#25

Post by wruza » Thu, Dec 08, 2016, 10:58 PM UTC

Piskvorrr wrote: post #20

jcoffland wrote: post #15

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.

For a tool that's supposed to be on most desktops by default, Explorer has some strange inefficiencies, such as the estimation and the loooong "preparing to copy" phase. Perhaps they are carried over from the old Windows NT codebase?

Of course they are. MS is biggest visual theme seller on the planet.

Re: The Finder’s GUI tax can be very expensive

#26

Post by headcanon » Thu, Dec 08, 2016, 11:02 PM UTC

advisedwang wrote: post #2

How did they not title this "Finders Fee"

Heh.

Re: The Finder’s GUI tax can be very expensive

#27

Post by Someone » Thu, Dec 08, 2016, 11:02 PM UTC

jcoffland wrote: post #15

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.

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.

Re: The Finder’s GUI tax can be very expensive

#28

Post by headcanon » Thu, Dec 08, 2016, 11:03 PM UTC

robotmlg wrote: post #19

__jal wrote: post #9

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

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

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

Re: The Finder’s GUI tax can be very expensive

#29

Post by headcanon » Thu, Dec 08, 2016, 11:05 PM UTC

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.

Re: The Finder’s GUI tax can be very expensive

#30

Post by eric_h » Thu, Dec 08, 2016, 11:10 PM UTC

pvg wrote: post #24

patio11 wrote: post #16

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 lar…

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.