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.

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.

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.

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

True enough.

2>&1>/dev/null

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.