Let's talk about performance

[unphased]

I tried to switch to wezterm for a while because it has better features, and I'm really impressed with Ghostty here in particular with the terminal inspector feature.

But i always come back to using alacritty, and the reason is that most of the new modern terminals do more processing and limit the framerate when lots of changes are being produced, and eventually show the resulting frame.

I would like my terminal to have the maximum possible framerate and I would probably go beyond most people and say that even if intermediate paint states are incorrect to also go ahead and show them to me.

The most important thing about software that I'm running is to see that it is still running, or in the case of scrolling around to view data to let me get as high as framerate as possible while that is happening in order to be able to visually track the movement. So any sort of attempt to wait and collect more changes to resolve before updating the display buffer is counterproductive as far as I'm concerned.

Could this behavior be tweaked? how deeply is it embedded in the engine?

[rhodes-b]

Ghostty does not have vsync on by default for linux or macos, it should be running as fast as possible in fact in tui apps that dont attempt to sync rendering or slow down at all you can and will see tearing

[rhodes-b]

I found it

[unphased]

OK. But what I am experiencing is that ghostty feels sluggish running tmux, and it feels sluggish in a similar way that wezterm does, though maybe not quite as bad. Once I actually get the rest of my binds ported over to ghostty config i can drive it for longer.

[unphased]

I used to use iterm but ive been driving alacritty for 3 or 4 years now. I tested and yes I think iterm is pretty sluggish with my current tmux session and ghostty is indeed an improvement over iterm at least. it seems like my tmux session has gotten bloated enough at some point (a very long running tmux session) that everything except alacritty is just chugging on it.

I'm going to figure out a replacement for tmux over the next weeks and months because it's time for a change.

[rhodes-b]

I used to use iterm but ive been driving alacritty for 3 or 4 years now. I tested and yes I think iterm is pretty sluggish with my current tmux session and ghostty is indeed an improvement over iterm at least. it seems like my tmux session has gotten bloated enough at some point (a very long running tmux session) that everything except alacritty is just chugging on it.

I'm going to figure out a replacement for tmux over the next weeks and months because it's time for a change.

I hear zellij is pretty popular alternative to tmux not sure its speed related to tmux. If you dont need sessions then ghostty has everything builtin (tabs and splits)

[unphased]

Yes I've been eyeing zellij but what I've been realizing is my original motivations for using a terminal multiplexer are probably just not very compelling anymore.

I recently switched from running nvim in terminal to just using neovide instead. To help manage the windows, I put some functionality in place with hammerspoon. I don't think I'm planning to stop using neovide, so that's a nail in the coffin for tmux. I'd been using some complicated thing with tmux plugin manager to customize tmux's copy mode and scrollback handling and behavior. But it's just too many abstraction layers and I scroll up and down way too much day to day now that I'm spending most of the day constantly trying to navigate back and forth reviewing LLM authored code changes -- the workflow now requires much more optimization of tools outside of the code editor all of a sudden.

The only stuff actually valuable that tmux or any other multiplexer gives is stuff like

• ability to have sessions continue while screwing around with terminal emulator programs (which aren't relevant outside of tool experimentation periods)
• being able to survive window manager deaths (which aren't relevant under macOS)

Modern terminals address (some of) the rest of the compelling original reasons to use a multiplexer:

• persistence and accessibility of terminal sessions over ssh
• binary space partitioning tiling windowing for terminals

In light of this I plan to eliminate tmux from my workflow though in favor of using terminal emulator built in features, and that's primarily motivated by performance. I started to realize I can DIY my own scrollback persistence and session management type customization at the shell level, there are plenty of suitable places to do those things and bringing them under my own control will allow me to make them actually scale indefinitely.

So once I have that working I will be able to ditch tmux and eliminate all the complexities and performance snags that it brings. Sorry for oversharing.

[moderation]

There is an old thread in the beta Discord about tmux performance at https://discord.com/channels/1005603569187160125/1005603569711452192/1141017543386083418. I link to the original post from the Kitty author that highlighted the performance issues. Mitchell adds detail about the specific performance impacts of tmux.

Some folks value tmux sessions to the extent that they are willing to take the huge performance hit. If you are using tmux for tabs and splits in a terminal that has native splits and tabs and are not using sessions, you are choosing to negate almost all of the performance benefit you get from a terminal like Ghostty, Kitty, Wezterm.

[unphased]

To be honest it is partly about having the scrollback but giving that job to the terminal emulator is fine and less crummy performance. The main thing that it's about is the flexibility to hop in from another client.