Hacker News new | past | comments | ask | show | jobs | submit login

That would slow things down, since everything has to pass through the shell.

Plus you can have a program on a terminal without any shell at all.




Your terminal emulator (XTerm, Gnome Terminal, etc.) already sits between your shell and your windowing system, and does not notably slow things down.


That's because it's the baseline for comparison. Arguing that a baseline isn't slower than itself doesn't make any bit of sense at all. A more useful example would be a comparison against terminal multiplexers, and they can slow down terminal I/O quite noticeably.


> they can slow down terminal I/O quite noticeably

If you're using a GPU-accelerated terminal like alacritty to sink stdout many orders of magnitude faster than a human can possibly read it¹ it's noticeable, but otherwise it's not.

https://danluu.com/term-latency/ (^f tmux)

1: I personally don't understand the use case for this — when would you run a command that writes multiple screenfuls of output without anticipating it and not ^C and redirect it to a file or pipe it into a pager?


> If you're using a GPU-accelerated terminal like alacritty to sink stdout many orders of magnitude faster than a human can possibly read it it's noticeable

I wrote "noticeable" because I noticed. On a non-GPU accelerated terminal. When a single pane in tmux is generating a lot of output, it makes all other panes and tmux itself unresponsive, which is hard not to notice.

---

> https://danluu.com/term-latency/ (^f tmux)

Yes, please do read that article. alacritty + tmux is not meaningfully faster than Terminal.app + tmux despite the fact their performance without tmux has a 2x difference. The author neatly sums it up with the following phrase:

> Tmux and latency: I tried tmux and various terminals and found that the the differences were within the range of measurement noise.

---

> I personally don't understand the use case for this — when would you run a command that writes multiple screenfuls of output without anticipating it and not ^C and redirect it to a file or pipe it into a pager?

I have three things to say to you. First, have you ever run "make" on a large project before? Second, terminal UIs are a thing, and they write "multiple screenfuls of output" because there is insufficient support for partial updates. Lastly, and more importantly, graphical performance is the least of our concerns if you're passing every bit of output through the shell. It's going to affect I/O throughput regardless of whether it's going to be displayed on the screen or not.


Every feature slows things down.

You can still have a program on a terminal without a shell.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: