Performance issues with Wezterm integration

[mrjones2014]

I'm noticing a delay when switching panes when using Wezterm.

Moving from Neovim pane to Neovim pane is quick. Moving from Neovim pane to Wezterm pane has a noticeable delay. Wezterm to Wezterm and Wezterm to Neovim are quick

Wezterm version: 20230712-072601-f4abf8fd

Wezterm config:

local w = require('wezterm')
local config = {}

if w.config_builder then
	config = w.config_builder()
end

config.window_padding = {
	left = 0,
	right = 0,
	top = 0,
	bottom = 0,
}

-- config.color_scheme = 'OneDark (base16)'
config.color_scheme = 'nightfox'


local function is_vim(pane)
	return pane:get_user_vars().IS_NVIM == 'true'
end

local direction_keys = {
	Left = 'h',
	Down = 'j',
	Up = 'k',
	Right = 'l',
	-- reverse lookup
	h = 'Left',
	j = 'Down',
	k = 'Up',
	l = 'Right',
}

local function split_nav(resize_or_move, key)
	return {
		key = key,
		mods = resize_or_move == 'resize' and 'META' or 'CTRL',
		action = w.action_callback(function(win, pane)
			if is_vim(pane) then
				-- pass the keys through to vim/nvim
				win:perform_action({
						SendKey = { key = key, mods = resize_or_move == 'resize' and 'META' or 'CTRL' },
					}, pane)
			else
				if resize_or_move == 'resize' then
					win:perform_action({ AdjustPaneSize = { direction_keys[key], 3 } }, pane)
				else
					win:perform_action({ ActivatePaneDirection = direction_keys[key] }, pane)
				end
			end
		end),
	}
end

config.keys = {
	-- move between split panes
	split_nav('move', 'h'),
	split_nav('move', 'j'),
	split_nav('move', 'k'),
	split_nav('move', 'l'),
	-- resize panes
	split_nav('resize', 'h'),
	split_nav('resize', 'j'),
	split_nav('resize', 'k'),
	split_nav('resize', 'l'),
	-- splits
	{ key = '|', mods = 'SUPER', action = w.action.SplitHorizontal { domain = 'CurrentPaneDomain' }},
	{ key = '_', mods = 'SUPER', action = w.action.SplitVertical { domain = 'CurrentPaneDomain' }},
	{ key = '|', mods = 'SHIFT|SUPER', action = w.action.SplitHorizontal { domain = 'CurrentPaneDomain' }},
	{ key = '_', mods = 'SHIFT|SUPER', action = w.action.SplitVertical { domain = 'CurrentPaneDomain' }},
	-- remove Al+Enter binding
	{ key = 'Enter', mods = 'ALT', action = w.action.DisableDefaultAssignment },
}

return config

Neovim version: v0.9.2

Smart-Splits version: 1.2.4 Smart-Splits config (lazy config):

return {
	"mrjones2014/smart-splits.nvim",
	lazy = false,
	config = function()
		vim.keymap.set('n', '<C-h>', require('smart-splits').move_cursor_left)
		vim.keymap.set('n', '<C-j>', require('smart-splits').move_cursor_down)
		vim.keymap.set('n', '<C-k>', require('smart-splits').move_cursor_up)
		vim.keymap.set('n', '<C-l>', require('smart-splits').move_cursor_right)


		vim.keymap.set('n', '<A-h>', require('smart-splits').resize_left)
		vim.keymap.set('n', '<A-j>', require('smart-splits').resize_down)
		vim.keymap.set('n', '<A-k>', require('smart-splits').resize_up)
		vim.keymap.set('n', '<A-l>', require('smart-splits').resize_right)
	end
}

Originally posted by @laxman20 in https://github.com/mrjones2014/smart-splits.nvim/discussions/133

[mrjones2014]

More context in this comment: https://github.com/mrjones2014/smart-splits.nvim/issues/53#issuecomment-1767482644

[baahrens]

I have the same issue. Same version of wezterm. Interestingly enough it works fine on my mac and only fails on my linux machine. Maybe that helps with debugging this.

Edit: Tried this with nvim nightly and 0.9.1

[chuan2984]

same issue here, love the idea. But the delay is too noticable for me to even use it :(

[mrjones2014]

Does the issue still persist on latest Wezterm nightly? I still haven't been able to reproduce the issue.

[chuan2984]

@mrjones2014 sorry, are you saying that you no longer have this performance problem with the latest nightly build? I also saw your comment in navigator, is this what you use usually, just curious? this seems to be more complete

I also just pulled the nightly build of wezterm, the delay from nvim to wezterm is really slow, like about 1sec. This is like 2x the delay I had with Navigator, could this be my configuration?

another problem is with resizing, this is probably worse or the same, when i have two wezterm panes side by side, both filled with vim, resizing takes like 1-2sec to complete. but if only 1 side is terminal, the other vim, resizing is super fast

I also ran the list-clients --format=json command, it averages around 0.43s

[mrjones2014]

I haven't used Navigator in a long time, ever since I added the multiplexer integrations to this plugin. I'm on wezterm 20240203-110809-5046fc22 and I cannot reproduce the issue. There's virtually no delay at all for me.

Could you test the performance of resizing manually with the wezterm cli adjust-pane-size --amount 3 Left (the --amount and direction can be whatever you want).

[chuan2984]

wezterm cli adjust-pane-size --amount 3 Left

this is the same as list-client, about 0.4s 😢 ill go ahead and give your build a try, it might be my OS? i often sense a 1-5 sec delay doing brew, there seems to be always some kind of delay, i dont know if its wezterm specific

[mrjones2014]

this is the same as list-client, about 0.4s 😢

It seems like this is the core issue, as on my machine it's more like 0.0047s.

[mrjones2014]

Do you have performance issues just moving between wezterm splits, without Neovim or smart-splits.nvim involved at all?

[chuan2984]

Do you have performance issues just moving between wezterm splits, without Neovim or smart-splits.nvim involved at all?

No no no, that I dont have. Resizing, switching between tabs, panes, workspaces are instant.

[chuan2984]

this is the same as list-client, about 0.4s 😢

It seems like this is the core issue, as on my machine it's more like 0.0047s.

thank you for helping me. I was afraid that we were going to arrive at this conclusion :( . Any idea how I can troubleshoot that, theres definitely a noticable delay to any cli command, its the same in the default terminal too. Im on MacOs btw

[mrjones2014]

its the same in the default terminal too

This indicates to me that maybe it’s something to do with your shell config (like bash or zsh or fish shell config). Can you test in a shell without anything in .bashrc/.zshrc/config.fish?

[chuan2984]

This indicates to me that maybe it’s something to do with your shell config (like bash or zsh or fish shell config). Can you test in a shell without anything in .bashrc/.zshrc/config.fish?

commented out .zshrc and .bashrc, sourced still around 0.4s :(. Isnt there a command that can list out what exactly are run for how long between the start and the end of an execution?

LOL, i ran the same command via bash -c, it takes 0.001s. I wonder what is causing my zsh to take this long, unbelievable even with .zshrc commented out

[mrjones2014]

LOL, i ran the same command via bash -c, it takes 0.001s

hmm now that is interesting 🤔 can anyone else reproduce these results? @baahrens @laxman20

If so, it seems like the issue is related to either wezterm or zsh. It may be worth opening a related issue in the wezterm repo.

[chuan2984]

LOL, i ran the same command via bash -c, it takes 0.001s

hmm now that is interesting 🤔 can anyone else reproduce these results? @baahrens @laxman20

If so, it seems like the issue is related to either wezterm or zsh. It may be worth opening a related issue in the wezterm repo.

Sorry I made a mistake since wezterm isnt sourced in bash. The result is actually the same as zsh. So i guess theres some system wide thing thats limiting this

I also asked a friend to install on another almost new Macbook Pro M2, fresh brew install wezterm, and got 0.4 as total. I wonder if its a macos thing or something that our company installs for security

[mrjones2014]

My test was run on macOS, same hardware as you, and I got 0.0047s 🤔

[chuan2984]

My test was run on macOS, same hardware as you, and I got 0.0047s 🤔 Im asking another coworker to test since we use the same models of macbook pros, im wondering if its one of these 'monitoring' apps that we have. It is really weird.

I tried using set -x and zsh -vx to see bg commands that are run alongside each command, but theres nothing. Theres only a delay after executing the wezterm cli command :(. very sad. but thanks for the continuing back and forth!

[mrjones2014]

@chuan2984 would you please file an issue in the wezterm repo? You can link this as a related issue, and tag me since I’m very interested what the issue is.

Closing this one since it seems we’ve determined it’s on Wezterm CLI’s end and not an issue with the plugin.