The Finder’s GUI tax can be very expensive
robservatory.com
The Finder’s GUI tax can be very expensive
1–10 of 125 posts
Re: The Finder’s GUI tax can be very expensive
#2How did they not title this "Finders Fee"
Re: The Finder’s GUI tax can be very expensive
#3"Finder (nee Archive Utility) should just execute the task without any visual feedback" -- no.
Re: The Finder’s GUI tax can be very expensive
#4If 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.
Re: The Finder’s GUI tax can be very expensive
#5"Finder (nee Archive Utility) should just execute the task without any visual feedback" -- no.
I also thought that was wrong. One idea is a progress window if the task takes more than a few seconds, plus some visual indicator for success.
Re: The Finder’s GUI tax can be very expensive
#6If 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.
Re: The Finder’s GUI tax can be very expensive
#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.
Re: The Finder’s GUI tax can be very expensive
#8"Finder (nee Archive Utility) should just execute the task without any visual feedback" -- no.
I also thought that was wrong. One idea is a progress window if the task takes more than a few seconds, plus some visual indicator for success.
This isn't a dichotomy. It's possible to make a fast-performing GUI for this task. The GUI is slow due to poor engineering.
Re: The Finder’s GUI tax can be very expensive
#9They should make the UI idiom feeding your file a mushroom and then double the icon size on completion.
Re: The Finder’s GUI tax can be very expensive
#10"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.