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

41–50 of 125 posts

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

#41

Post by mwfunk »

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.

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

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

#42

Post by flashman »

mwfunk wrote: post #41
pvg wrote: post #24

Earlier quoted context omitted.

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

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

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

#43

Post by oneeyedpigeon »

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

I think an 'in-line' style of alert can work well in this situation, like a status bar but closeable. It can be dealt with at a time most convenient to the use, still provides feedback. It could even just display the output of a CLI command with a given flag, even for a small subset of 'blessed' commands if necessary.

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

#44

Post by arnarbi »

radley wrote: post #35
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, 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??"

Then just don't show a dialog.

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

#45

Post by leereeves »

arnarbi wrote: post #44
radley wrote: post #35

Earlier quoted context omitted.

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??"

Then just don't show a dialog.

Then users wonder "Did it actually save?"

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

#46

Post by thaumasiotes »

dijit wrote: post #31
headcanon wrote: post #29

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.

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

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.

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

#47

Post by goldenkek »

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? ;)

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

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

#49

Post by goldenkek »

ythn wrote: post #40

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.

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