Keystrokes!! Way to come up with a strawman. Every byte that the program running inside tmux send to the terminal has to be parsed and re-interpreted by tmux first and then the actual terminal. Same for every byte that the terminal sends the program running inside it. These include every byte used to redraw the screen, which with modern full screen applications like editors can be several kilobytes per screen refresh. Keystrokes indeed. This reduces throughput by a factor for 2 at a minimum, reference: https://sw.kovidgoyal.net/kitty/performance/#throughput see the table entries for alacritty vs alacritty+tmux. And that is just throughput, tmux will affect latency as well, though I dont have a reference to measurements handy at the moment.
Just off the wall crazy shit dealing with absolutists like this.
Yes efficiency is good. But... Damnit man! The performance numbers shown for this low power processor are 43MB/s without tmux vs 30MB/s with tmux. It's likely going to take a lot of activity for that to aggregate into even a decent fraction of a ms of latency.
Beware extremists. Some people will never be pleased, will accept nothing. The only answer is to cut cut cut forever. There's a cult of people out there that idolize performance above any practical use like a god & will destroy & savage anything else. Deny this falsity. Respect performance, but also allow other factors to balance in.
(Side note: I'd love to know how dtach performs. It has the key advantage to me of tmux, which is detachability, but no virtualization. Great for running a vim session! And by design is a very pure simple pass through.)
First I dont know what table you are looking at, but its 54MB/s vs 24 MB/s on average across different data types. That's a factor of 2. Aka half the throughput. I dont know what kind of performance engineering you do, but a halving of throughput is a pretty serious performance regression where I come from.
Also, latency is not a direct function of throughput. The two are separate. In this case the latency will come because when you have tmux in the middle it means your command line program writes to a pipe, which is a buffer in the kernel. tmux then has to read from that pipe, then it has to process that byte updating its internal state, then it has to generate the output bytes based on the internal state, those output bytes are written to another pipe, and finally the terminal reads from that second pipe.
There is a whole extra pipe with associated context switches for every byte (or more accurately every packet since reads/writes on a pipe are buffered). This will add latency for example for every keystroke no matter what the throughput numbers are. A pipe operation requires a poll on the pipe fd which is a context switch. Apart from whatever internal processing tmux does, there are four extra context switches added for every keystroke + response.
The table you linked is chopped off on mobile. So you are looking at the last column and the person above is looking at the first column.
Also, why have you done an “alacritty” vs “alacritty+tmux” benchmark yet have not done a “kitty+tmux” benchmark on this same table? That’s a big omission. The entire conversation is about the effects of adding a multiplexer on top of a terminal.
I didnt do the table go ask the kitty developer why he did that. Or just read the notes under the table where he tells you why he included alacritty+tmux.
