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

31–40 of 125 posts

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

#31

Post by dijit »

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.

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

#32

Post by orf »

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.

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.

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

#33

Post by ben0x539 »

eric_h wrote: post #30
pvg wrote: post #24

Earlier quoted context omitted.

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

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

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

#34

Post by 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?

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

#35

Post by radley »

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

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

#36

Post by syrrim »

TheAceOfHearts wrote: post #4

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

The unarhiver also handles .rar files, whih archive utility can't do.

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

#37

Post by [deleted] »

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.

[deleted]

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

#38

Post by aplummer »

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…

I have been made to do this, I called the function wasteMyTime() and all it did was waste the user's time for a few seconds with a spinner. Still a little bitter about it.

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

#39

Post by pvg »

vortico wrote: post #34

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?

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.

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

#40

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