Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oh-my-zsh on WSL2 has unstable launching speed #4256

Closed
MichaelTong opened this issue Jul 1, 2019 · 14 comments
Closed

oh-my-zsh on WSL2 has unstable launching speed #4256

MichaelTong opened this issue Jul 1, 2019 · 14 comments

Comments

@MichaelTong
Copy link

MichaelTong commented Jul 1, 2019

  • Your Windows build number:
    10.0.18922.1000

  • What you're doing and what's happening:
    Installed oh-my-zsh, the launch speed of an Ubuntu terminal becomes unstable.

  • What's wrong / what should be happening instead:
    So after I upgrade Ubuntu instance to WSL-2, I found the launch speed of oh-my-zsh became even worse -- around 5 seconds.

Other options I have tried include install a new instance, launching zsh without oh-my-zsh.

With a new instance, launch speed was good (likely 1~2 seconds) at the beginning, but after one day of normal PC use (no heavy WSL use), it became slower and slower (around 5 seconds).

Launching zsh without oh-my-zsh is always as good as bash without any configurations.

Does this mean there is some bottleneck for reading all the configuration and resource files for oh-my-zsh?

  • Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).

Not sure what to get, but I'll try when I got time.

EDIT:
After one day I reinstalled oh-my-zsh, it took around 3s to load everything.
I added a line in .zshrc so it can print timestamps while zsh is loading

setopt prompt_subst; zmodload zsh/datetime; PS4='+[$EPOCHREALTIME]%N:%i> '; set -x

So when I installed oh-my-zsh, I printed out the log and save it to a file named fast_log.txt, then I turned the printing off by commenting the line above in .zshrc. Today, when I found it got slow, I turn the printing on and grabbed the log three times when I tried to launch zsh three times. I saved them into slow_log.txt, slow_log_2.txt and slow_log_3.txt.

I also write a little script to compare fast and slow logs, it turned out there are a few steps in the slow log that take >0.1s more than those steps in the fast log.

They are:

8 0.1414494514465332 0.0013909339904785156 0.14284038543701172 /home/michaelht/.oh-my-zsh/oh-my-zsh.sh:13> [ '' '!=' true ']'
34 0.5684547424316406 0.046172142028808594 0.6146268844604492 handle_completion_insecurities:13> insecure_dirs=( )
276 0.2090909481048584 0.0011241436004638672 0.21021509170532227 grep-flag-available:1> echo
1456 0.35894012451171875 0.0007147789001464844 0.35965490341186523 /home/michaelht/.oh-my-zsh/lib/theme-and-appearance.zsh:32> ((  1  ))

The first column is a line number in fast_log.txt, second column is the time difference between fast_log and slow_log, third and forth are fast latency and slow latency for that step, last column is the traced step.

zsh logs are here: https://gist.github.com/MichaelTong/5626016120be35c250a2c1e0fdd7b449

@msftbot
Copy link
Contributor

msftbot bot commented Jul 1, 2019

We’ve labelled your issue as ‘need-repro’ since we need more steps to help identify your problem. Could you please provide us with reproducible steps for the issue you’re experiencing, including things such as the specific command line steps necessary to reproduce the behavior and their output. Thank you! -The WSL Team

@MichaelTong
Copy link
Author

Updated original issue with zsh logs and some comparison

@therealkenc
Copy link
Collaborator

Dropped need-repro out of respect for the effort (thanks). Unfortunately there isn't anything in the zsh logs that jumps out as the source of the problem.

I've got one hail mary thing you might try. Create a /etc/wsl.conf with:

[automount]
enabled = false

[interop]
appendWindowsPath = false

You'll need to do a wsl.exe --shutdown after the change (or reboot).

That isn't intended as a "fix" of course, but if the the speed improves with /mnt/c not mounted, it might hint at the cause. Might.

@MichaelTong
Copy link
Author

After I upgrade to 18936 last week, this issue doesn't seem to happen again. I'll close this issue for now.

@OmriSama
Copy link

Dropped need-repro out of respect for the effort (thanks). Unfortunately there isn't anything in the zsh logs that jumps out as the source of the problem.

I've got one hail mary thing you might try. Create a /etc/wsl.conf with:

[automount]
enabled = false

[interop]
appendWindowsPath = false

You'll need to do a wsl.exe --shutdown after the change (or reboot).

That isn't intended as a "fix" of course, but if the the speed improves with /mnt/c not mounted, it might hint at the cause. Might.

I just wanna say you were so right. I'm so glad it was easy finding my solution to this problem.

@camuthig
Copy link

I ran into this same issue today. In my case, it appeared to be related to altering the PATH variable. I have a line like $HOME/.local/bin:$PATH in my .zshrc file. With this line in place, the initialization of zsh was very slow but also made each command and subsequent rendering of the prompt slow.

I did see a small performance boost by removing the sourcing of the oh-my-zsh.sh configuration file, but this was barely perceptible.

I used only the suggestion regarding removing the Windows path from WSL (appendWindowsPath = false) and resolved the issue. I only started using WSL 2 today, so I'm not sure if that will later impact my use of WSL.

Also, including the same line in my .bashrc file does not cause a slow down on loading or subsequent commands.

Windows version: 10.0.19041.1

@anderswei
Copy link

it seems the problem is the PATH variable.
if you echo $PATH you can see the windows PATH is passed to WSL2 as well:

/mnt/c/WINDOWS/system32
/mnt/c/WINDOWS
/mnt/c/WINDOWS/System32/Wbem
/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/
/mnt/c/WINDOWS/System32/OpenSSH/
/mnt/c/ProgramData/chocolatey/bin
/mnt/c/Program Files/Microsoft SQL Server/130/Tools/Binn/
/mnt/c/Program Files/Microsoft SQL Server/Client SDK/ODBC/170/Tools/Binn/
/mnt/c/Program Files/Java/jdk1.8.0_221/bin
/mnt/c/ProgramData/chocolatey/lib/maven/apache-maven-3.6.2/bin
/mnt/c/Program Files/Git/cmd
/mnt/c/Program Files (x86)/ZeroTier/One/
/mnt/c/Program Files/Microsoft SQL Server/Client SDK/ODBC/110/Tools/Binn/
/mnt/c/Program Files (x86)/Microsoft SQL Server/120/Tools/Binn/ManagementStudio/
/mnt/c/Program Files (x86)/Microsoft SQL Server/120/Tools/Binn/
/mnt/c/Program Files/Microsoft SQL Server/120/Tools/Binn/
/mnt/c/Program Files (x86)/Microsoft SQL Server/120/DTS/Binn/
/mnt/c/Program Files/Microsoft SQL Server/120/DTS/Binn/
/mnt/c/Program Files/dotnet/
/mnt/c/Program Files/nodejs/
/mnt/c/Users/xx/AppData/Local/Microsoft/WindowsApps
/mnt/c/Users/xxx/AppData/Local/Programs/Microsoft VS Code/bin
/mnt/c/Users/xxx/AppData/Roaming/npm

it seems zsh will loop those directories for auto-complete, due to the cross os file system performance issue, this introduced lots of lag.
To fix this problem, simply add the following line in the beginning of your .zshrc file.

export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

@Po-wei
Copy link

Po-wei commented Mar 22, 2020

@anderswei

I think the windows path would be useful when we need interop.

For examples, use code.exe , explorer.exe in WSL.

@rishabhdeepsingh
Copy link

@anderswei The same path is on bash as well but it is not slow as zsh. is there any other solution?

@eromoe
Copy link

eromoe commented Jul 2, 2020

I want zsh do auto-complete for windows path ,but just don't do it at start up , what should I do ??
Because I need use code.exe and explorer.exe in wsl2 . I also found it didn't speed up much when I comment the windows paths. How do I found which line slow down zsh ?

@Martichou
Copy link

@eromoe you can just add an export for your code.exe and explorer.exe in your .zshrc or .bashrc.

export PATH='/mnt/c/Users/marti/AppData/Local/Programs/Microsoft VS Code/bin':$PATH

The above add code . after removing the WindowsPath from your Linux's one (see #4256 (comment)).

@eromoe
Copy link

eromoe commented Jul 30, 2020

@Martichou Not that problem, I commented those paths , however it is still slow .

@trallnag
Copy link

@eromoe Declare functions that call these executables

@SimonG97
Copy link

Dropped need-repro out of respect for the effort (thanks). Unfortunately there isn't anything in the zsh logs that jumps out as the source of the problem.
I've got one hail mary thing you might try. Create a /etc/wsl.conf with:

[automount]
enabled = false

[interop]
appendWindowsPath = false

You'll need to do a wsl.exe --shutdown after the change (or reboot).
That isn't intended as a "fix" of course, but if the the speed improves with /mnt/c not mounted, it might hint at the cause. Might.

I just wanna say you were so right. I'm so glad it was easy finding my solution to this problem.

@eromoe you can just add an export for your code.exe and explorer.exe in your .zshrc or .bashrc.

export PATH='/mnt/c/Users/marti/AppData/Local/Programs/Microsoft VS Code/bin':$PATH

The above add code . after removing the WindowsPath from your Linux's one (see #4256 (comment)).

When auto mount is disable wholed c mount is removed from the wsl so how can we access the code . of the windows?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests