News for hackers. Stuff that matters.

A comment on The Finder’s GUI tax can be very expensive.

Re:The Finder’s GUI tax can be very expensive by headcanon on Thursday December 08, 2016 @06:05PM (#13135150)
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.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by dijit on Thursday December 08, 2016 @06:16PM (#13135230)
quiet reminder that writing to file descriptors is blocking.

STDERR and STDOUT are file descriptors.

[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by orf on Thursday December 08, 2016 @06:22PM (#13135271)
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.

[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by colemickens on Friday December 09, 2016 @12:17AM (#13136838)
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.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by thaumasiotes on Thursday December 08, 2016 @08:21PM (#13135902)
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.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by arjie on Friday December 09, 2016 @01:07AM (#13137013)
It's a combination of many things. You're probably writing to a file buffered, but terminal writes are generally unbuffered. In addition, I had a terminal setup once that just did a poor job of displaying text (line wrapping was slow, perhaps) and programs that would write out to stdout would be slow.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by majewsky on Friday December 09, 2016 @09:27AM (#13138893)
> printing to stdout is much, much, much, much slower than printing to a file

False dichotomy. stdout can very well be a file. What you mean is that printing to a terminal is slower than to a file.

[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by thaumasiotes on Saturday December 10, 2016 @12:22PM (#13146677)
True enough.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by anthk on Thursday December 08, 2016 @09:39PM (#13136272)
2>&1>/dev/null
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by goldenkek on Thursday December 08, 2016 @08:38PM (#13135977)
blocking. blocking. blocking. blocking. rtfm
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by thaumasiotes on Thursday December 08, 2016 @10:03PM (#13136349)
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.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by anthk on Thursday December 08, 2016 @09:38PM (#13136266)
Avoid verbose flags on tar.
[ Parent | on HN ]
Re:The Finder’s GUI tax can be very expensive by jmiserez on Friday December 09, 2016 @03:26PM (#13141542)
rsync as well, especially the progress bars.
[ Parent | on HN ]