Duplicating tab is *significantly* slower than new tab

[jaybosamiya-ms]

Windows Terminal version

1.21.3231.0

Windows build number

10.0.26100.0

Other Software

zsh 5.9 (x86_64-ubuntu-linux-gnu)

Steps to reproduce

1. Set default profile to Ubuntu (might not be necessary, but I have only tested this on Ubuntu, with zsh as my shell)
2. Make sure that the PWD tracking is set up

   if test -n "$WT_SESSION"; then
       # See https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory
       __keep_current_path() { printf "\e]9;9;%s\e\\" "$(wslpath -w "$PWD")" }
       precmd_functions+=(__keep_current_path)
   fi

3. Open new tab---this is always practically instant
4. Duplicate the tab---this sometimes takes 30s to even a minute; most of the times, this is roughly as fast as opening a new tab, but other times, it takes a long time (obviously, this is not WSL spin-up time, because WSL it already running, and even opening a new tab works immediately). No clear pattern to when it is going take longer to duplicate a tab though.

Expected Behavior

Duplicating a tab should not be faster than opening a new tab and running cd {prev tab working directory}

Actual Behavior

Duplicating the tab (sometimes) literally takes longer than me re-typing the whole path out by hand.

[jaybosamiya-ms]

Do let me know if I can enable some tracing/logging that might help provide more details the next time that I hit upon the slowdown, to help reproduce the issue.

[lhecker]

This is one of those times again where https://superluminal.eu/ would be super helpful...

I think as a basic triage you could try and see how fast Windows Terminal launches wsl.exe and OpenConsole.exe, by watching the process tree via https://systeminformer.sourceforge.io/ (or alternatively https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer). Does it happen instantly? If so, then it's at least quite a bit less likely to be a bug in Windows Terminal.

[zadjii-msft]

My guess is that passing a path to wsl -cd is what's tripping us up here. I'd bet wsl is evaluating the path slowly

[jaybosamiya-ms]

I do semi-regularly run into the issue but haven't had it happen while I have the process tree viewer open. I will ping here again if I am able to hit the issue while the viewer is open.

At least wrt wsl --cd I don't think that is the issue (at least not on its own):

$ hyperfine 'wsl.exe exit' 'wsl.exe --cd ~ exit' 'wsl.exe --cd / exit' 'wsl.exe --cd /tmp exit' 'wsl.exe --cd /not_exist exit' 'wsl.exe --cd ~/not_exist exit'
Benchmark 1: wsl.exe exit
  Time (mean ± σ):     262.8 ms ±   7.1 ms    [User: 2.5 ms, System: 0.2 ms]
  Range (min … max):   254.5 ms … 278.2 ms    10 runs

Benchmark 2: wsl.exe --cd ~ exit
  Time (mean ± σ):     204.3 ms ±  26.0 ms    [User: 2.0 ms, System: 0.1 ms]
  Range (min … max):   183.1 ms … 261.6 ms    11 runs

Benchmark 3: wsl.exe --cd / exit
  Time (mean ± σ):     179.7 ms ±   5.5 ms    [User: 1.5 ms, System: 0.5 ms]
  Range (min … max):   172.4 ms … 195.1 ms    15 runs

Benchmark 4: wsl.exe --cd /tmp exit
  Time (mean ± σ):     176.8 ms ±   4.0 ms    [User: 1.7 ms, System: 0.2 ms]
  Range (min … max):   171.2 ms … 186.2 ms    16 runs

Benchmark 5: wsl.exe --cd /not_exist exit
  Time (mean ± σ):     177.9 ms ±   3.0 ms    [User: 1.6 ms, System: 0.1 ms]
  Range (min … max):   173.3 ms … 182.6 ms    16 runs

Benchmark 6: wsl.exe --cd ~/not_exist exit
  Time (mean ± σ):     177.0 ms ±   3.9 ms    [User: 1.6 ms, System: 0.1 ms]
  Range (min … max):   172.2 ms … 185.8 ms    16 runs

Summary
  wsl.exe --cd /tmp exit ran
    1.00 ± 0.03 times faster than wsl.exe --cd ~/not_exist exit
    1.01 ± 0.03 times faster than wsl.exe --cd /not_exist exit
    1.02 ± 0.04 times faster than wsl.exe --cd / exit
    1.16 ± 0.15 times faster than wsl.exe --cd ~ exit
    1.49 ± 0.05 times faster than wsl.exe exit

These are all within a small factor of each other (more than I would expect due to noise, but not enough to worry about). The behavior I have seen wrt slow-duplicating-tab is literally over a minute of waiting time.

[carlos-zamora]

Is the rest of the UI still interactive while "duplicate tab" is executing /? This'll help us figure out where the issue may be occurring.

Also, what other shell integrations do you have set up, if any?

[jaybosamiya-ms]

Yes, rest of the UI is indeed still interactive. More details:

• While "duplicate tab" appears to be stuck (i.e., waiting for 1~2 minutes before that tab responds)

  • Overall Windows Terminal UI is still responsive
  • Can use "new tab" and that will work instantly
  • Running another "duplicate tab" leads to a new tab that is similarly stuck
  • Running Ctrl-C in the "stuck" tab causes the tab to quit trying to run WSL in it (I don't have the message available right now to confirm, but unless I'm mistaken, it is the standard "process exited" one)
  • Waiting for the 1~2 minutes causes it to get unstuck, and behave with regular performance going forward

• After the "duplicate tab" gets unstuck / when not in the occasional "duplicate tab is stuck" case

  • UI is responsive as usual
  • Running "duplicate tab" again no longer is slow, is roughly same speed as "new tab"
  • Running Ctrl-C immediately after opening a new tab (but before shell is fully initialized) drops me to a basic zsh shell (i.e., without the fancy setup) but never goes into the "process exited" state mentioned above

Shell integrations: the Windows Terminal integration is here: https://github.com/jaybosamiya-ms/dotfiles/blob/3a17d8c8bdbcfd3c2cfe743ec185bf46371d50a1/chezmoi/dot_zshrc#L567-L580 ; I know my zshrc is fairly sizable, but most of it (everything other than the WT-specific code that I've linked) should have no impact on tab duplication (it is all highly tested code, used on many machines, over many different terminals, and operating systems, across many years, some including Windows Terminal; by process of elimination, the linked code is the narrowest root cause).