Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Finder’s GUI tax can be very expensive

robservatory.com

Post reply on HN
Print view View original

61–70 of 125 posts

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

#61

Post by thaumasiotes »

goldenkek wrote: post #51
thaumasiotes wrote: post #46

Earlier quoted context omitted.

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.

blocking. blocking. blocking. blocking. rtfm

Again, the problem is not that writing to file descriptors is blocking. The problem is that writing to the screen is very slow. Writing to a file is just as blocking, but you'll block for much less time, because writing to a file is not slow.

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

#63

Post by userbinator »

fredsir wrote: post #23
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,…

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.

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

#65

Post by matheusmoreira »

TazeTSchnitzel wrote: post #17
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…

This reminds me of how some PlayStation game's developers complained that they were required by Sony to add a false multi-second delay to their game's save routine, so the user would have enough time to read the mandatory warning not to turn off the console. Their game in fact saved so quickly there needn't be a warning at all.

This is really interesting. I read that warning every time I save and I never noticed the delay. For some reason, it doesn't bother me like the archive utility animations. I guess it's because saving the game is a such ritualized action.

I wonder what other requirements Sony imposed on developers. Maybe they have their own video game-oriented human interface guidelines. Do you have a source for this information? I found plenty of technical documents and SDKs but nothing about interfaces.

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

#66

Post by waterhouse »

fredsir wrote: post #23
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,…

If they're simply following UX recommendations blindly, they could go for this one:

"Use a progress indicator for any action that takes longer than about 1.0 second."

https://www.nngroup.com/articles/progress-indicators/

You don't necessarily know in advance whether it'll take 1 second, but I think a strategy that would work is: after 1 second, if the task is not done, open a progress bar, and if the task completes immediately after that, display the completed progress bar for 500 milliseconds or something before closing it.

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

#67

Post by aidenn0 »

wruza wrote: post #21
hbosch wrote: post #10

Earlier quoted context omitted.

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.

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

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

#68

Post by aidenn0 »

Someone wrote: post #27
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,…

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.

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

#69

Post by colemickens »

orf wrote: post #32
dijit wrote: post #31

Earlier quoted context omitted.

quiet reminder that writing to file descriptors is blocking. STDERR and STDOUT are file descriptors.

Yep, and this is very noticeable if your using windows and select any portion of the terminal. All stdout/stderr is blocked. I had a call when one of our services stopped responding. Took a while to figure out there was a tiny one-character selection in the power shell.

I often wonder if its why it took them over a decade (two decades?) to enable QuickEdit mode by default. Sometimes I'll wonder why something is taking so long and realize that my palm accidentally caused a quickedit selection in cmd.exe.

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

#70

Post by pvg »

ben0x539 wrote: post #33
eric_h wrote: post #30

Earlier quoted context omitted.

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

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.
Post reply on HN