mrjones2014 / smart-splits.nvim

🧠 Smart, seamless, directional navigation and resizing of Neovim + terminal multiplexer splits. Supports tmux, Wezterm, and Kitty. Think about splits in terms of "up/down/left/right".
MIT License
906 stars 38 forks source link

Smart-splits.nvim + Wezterm (performance issue) #53

Closed mrjones2014 closed 1 year ago

mrjones2014 commented 1 year ago

Solution

Make sure you are using Wezterm with this commit included: https://github.com/wez/wezterm/commit/96f1585b103162b042e2593567884dfcbe32ca21

Discussed in https://github.com/mrjones2014/smart-splits.nvim/discussions/52

Originally posted by **masoniis** April 4, 2023 Does anyone else use Wezterm as their terminal emulator alongside this plugin? I noticed that on Wezterm there is a noticeable delay (maybe 500-1000ms) when performing a circular window navigation (and this doesn't appear when I switch to macOS default terminal). I'm not sure if this is a fixable problem, or if it's just a result of the slowness of Wezterm itself when paired with the circular navigation.
mrjones2014 commented 1 year ago

It comes from here, but this change introduces a bug. tl;dr we need a more performant way to get current active pane id.

function M.current_pane_id()
  -- local output = wezterm_exec({ 'list-clients', '--format=json' })
  -- local data = vim.json.decode(output)
  -- if #data == 0 then
  --   return nil
  -- end
  -- -- if more than one client, get the active one
  -- if #data > 1 then
  --   table.sort(data, function(a, b)
  --     return a.idle_time.nanos < b.idle_time.nanos
  --   end)
  -- end
  -- return data[1].focused_pane_id
  return vim.env.WEZTERM_PANE
end
wez commented 1 year ago

FWIW, the tuple of idle_time.secs and idle_time.nanos describes the total idle time. Comparing only the nanos will lead to inconsistent results.

I also want to note that https://github.com/wez/wezterm/commit/11dc59b6130357bdb2f83377ea8c5d77b53fc6f2 fixes an issue where background activity from a client may falsely make it appear as though that client is no longer idle.

Regarding the change you indicate in the comment: are you saying that commenting out the exec and the json decoding solved the performance problem? What if you restore the exec but omit the json manipulation?

mrjones2014 commented 1 year ago

So weird development, I switched from my mac to my linux PC and I no longer experience the issue :thinking:

@masoniis what OS were you using?

mrjones2014 commented 1 year ago

are you saying that commenting out the exec and the json decoding solved the performance problem?

Yeah that's what it seemed like.

masoniis commented 1 year ago

@masoniis what OS were you using?

I'm on MacOS Ventura 13.2.1, but I also run arch linux on my desktop. Haven't verified whether or not the latency is there on arch, though.

mrjones2014 commented 1 year ago

What if you restore the exec but omit the json manipulation?

@wez back on my mac, if I restore the exec but omit the JSON parsing and sorting, the issue still persists. So I think its the performance of wezterm cli list-clients --json that's the issue.

mrjones2014 commented 1 year ago

Would there be that much of a performance disparity between platforms though? I tried again and the issue is not noticeable at all IMO on my Linux PC, but it very noticeable on my Mac.

wez commented 1 year ago

If you run time wezterm cli list-clients --format=json a few times on your mac, what's the latency look like? For me, it's in the 13-20ms range; slower than my linux box, but not terribly slow.

Do you have any kind of antivirus/security type software installed on your mac? I'm thinking of things like https://github.com/google/santa that can slow down execution of processes that are not placed onto an allowlist.

mrjones2014 commented 1 year ago

Its consistently around 30-34ms for me on an M1 Max Macbook Pro.

I don't have anything like Santa installed on my system.

mrjones2014 commented 1 year ago

I thought it might be executing through Rosetta or something because that seems weird that it would take that long, but uname -m outputs arm64 which means it is running natively.

wez commented 1 year ago

Not directly related to this, but I just added wezterm cli get-pane-direction; it will print out the pane id in the specified direction, if there is one.

mrjones2014 commented 1 year ago

Using that does help performance when config.wrap_at_edge = false, because it eliminates the need for an extra current pane ID check 👍

mrjones2014 commented 1 year ago

I'm seeing drastically improved performance using the new API from https://github.com/wez/wezterm/commit/96f1585b103162b042e2593567884dfcbe32ca21 🎉

mrjones2014 commented 1 year ago

time wezterm cli list --format json averages about 3ms. Much better than list-clients

mrjones2014 commented 1 year ago

Thanks a ton to Wez for all his help with this issue!

laxman20 commented 11 months ago

I was wondering if this problem has re-appeared for anyone. I'm using wezterm version 20230712-072601-f4abf8fd, which I believe contains the fix mentioned.

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

mrjones2014 commented 11 months ago

wezterm version 20230712-072601-f4abf8fd

I'm on the exact same version and do not experience the issue, all 3 cases you mentioned are near-instant for me. If you open a GitHub Discussion and post your smart-splits.nvim and Wezterm configs, I can try to help you diagnose the issue you're having.

Just to make sure, are you also on the latest version of Neovim and smart-splits.nvim?

laxman20 commented 11 months ago

wezterm version 20230712-072601-f4abf8fd

I'm on the exact same version and do not experience the issue, all 3 cases you mentioned are near-instant for me. If you open a GitHub Discussion and post your smart-splits.nvim and Wezterm configs, I can try to help you diagnose the issue you're having.

Just to make sure, are you also on the latest version of Neovim and smart-splits.nvim?

Thanks! Created a discussion here https://github.com/mrjones2014/smart-splits.nvim/discussions/133