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

Bash extremely slow in 15046 #1739

Closed
thenitai opened this Issue Mar 2, 2017 · 26 comments

Comments

Projects
None yet
7 participants
@thenitai

thenitai commented Mar 2, 2017

Bash is extremely slow in the latest build. I'm doing some removal of a directory or even just starting up and switching to the ZSH shell takes well over 6 seconds.

Some examples:

Removing a node_modules directory:

#  rm -rf node_modules
0.12s user 13.91s system 84% cpu 16.662s total
0.09s user 3.42s system 115% cpu 3.054s total
0.00s user 0.00s system 0% cpu 3.048s total
0.09s user 3.28s system 120% cpu 2.796s total

On Windows removing the SAME directory takes like 4 seconds

Switching to ZSH:

3.97s user 4.22s system 121% cpu 6.758s total
0.06s user 3.52s system 118% cpu 3.012s total
@benhillis

This comment has been minimized.

Member

benhillis commented Mar 3, 2017

I've seen cases where node adds some things to .bashrc that really slow us down. Could you try creating a new user account to see if that is also slow?

close bash.exe
lxrun.exe /setdefaultuser newuser
bash.exe

restore your old user with
lxrun.exe /setdefaultuser oldusername

@thenitai

This comment has been minimized.

thenitai commented Mar 3, 2017

What kind of "things" does node add? I don't see anything out of the ordinary in .bashrc

@benhillis

This comment has been minimized.

Member

benhillis commented Mar 7, 2017

I'm not sure if it's node, npm, or nvm but one of them adds a bunch of commands to bashrc. Would you mind sharing yours out?

@thenitai

This comment has been minimized.

thenitai commented Mar 7, 2017

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything

[ -z "$PS1" ] && return


#if test -t 1; then
#    # ...start zsh
#    exec zsh
#fi

# don't put duplicate lines in the history. See bash(1) for more options
# ... or force ignoredups and ignorespace
HISTCONTROL=ignoredups:ignorespace

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
#    . /etc/bash_completion
#fi
@bmayen

This comment has been minimized.

bmayen commented Mar 10, 2017

@thenitai, were you not seeing this same slowness in previous versions? Seems the same to me. Which is to say, it's still slow as ever. But slow filesystem IO is a well-known and documented issue with WSL.

@thenitai

This comment has been minimized.

thenitai commented Mar 10, 2017

@bmayen Bash in previous builds wasn't so slow. Else, I wouldn't waste time to comment on here.

@sunilmut

This comment has been minimized.

Member

sunilmut commented Mar 10, 2017

@thenitai - Thanks for your post. I am not entirely sure if it is your .bashrc that is causing the bash launch to be slow. I copied it over to my setup and it didn't seem to affect bash launch at all. But, slow bash launch seems to be documented elsewhere too. See the section on nvm.

@thenitai

This comment has been minimized.

thenitai commented Mar 10, 2017

I know that it is slower than native. However, as the title says, in the recent two builds it has become even slower. There is no NVM and nothing else running. On Windows side, nothing changed either.

@benhillis

This comment has been minimized.

Member

benhillis commented Jul 28, 2017

Recent insider builds should have a few changes that make both of these scenarios much faster. If you could retry on a recent Insider build it would be much appreciated.

@thenitai

This comment has been minimized.

thenitai commented Jul 28, 2017

I'm on the latest builds and honestly, do not see much speed improvements. I mainly use node (node-dev) that watches the file system for changes and it just seems slow (I mean compared to a Mac or Linux machine).

@liias

This comment has been minimized.

liias commented Jul 31, 2017

sdkman also adds two lines to .bashrc which added additional 1-2 seconds for me. Removed the lines, now is quite instant.
// I am not using insider build.

@thenitai

This comment has been minimized.

thenitai commented Aug 1, 2017

I'm using fish instead of zsh now. Startup is faster. However, node operation is still quite slow.

@thenitai

This comment has been minimized.

thenitai commented Aug 1, 2017

Update: I've been using Cmder most of the time. It turns out that thing is extremely slow. I'm working with the "official" shell now.

Things are faster, but node-dev and all apps that need to watch the file system are still kinda slow.

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

I'm on the fast ring Insider build. just doing rm-rf takes 40 seconds, while takes 2seconds on a mac

slow

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

I just tried it in a VM, in Ubuntu in VirtualBox, rm -rf those 220mb worth of files in node_modules takes sub-second speed, 0.4sec

so WSL is 100x slow. 😢

@benhillis

This comment has been minimized.

Member

benhillis commented Aug 9, 2017

@thisguychris - And how long does rmdir /s /q take from Windows?

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

rmdir /s /q on the node_modules folder? I had it cloned /home/user and not in mount, since I'm seeing performance regression on /mnt folder?

maybe that's the wrong command? rmdir /s only deletes empty sub-directories?

$ rmdir /s /q node_modules/
rmdir: failed to remove '/s': No such file or directory
rmdir: failed to remove '/q': No such file or directory
rmdir: failed to remove 'node_modules/': Directory not empty
@benhillis

This comment has been minimized.

Member

benhillis commented Aug 9, 2017

@thisguychris - yep. Would be interesting to compare Windows versus Mac natively. WSL can only hope to be as fast as Windows since we're relying on NTFS underneath. Creating and deleting files is something NTFS is not very fast at.

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

@benhillis what about win rfs would that bring windows comparable to *nixes?

@benhillis

This comment has been minimized.

Member

benhillis commented Aug 9, 2017

@thisguychris - The rmdir /s /q command must be run from a windows command prompt, not bash.

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

how do you time it? its pretty slow too? maybe 10 to 15 seconds? apologies, I thought exe commands are available in WSL.

@benhillis

This comment has been minimized.

Member

benhillis commented Aug 9, 2017

powershell Measure-Command { rmdir /s /q node_modules }

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

Remove-Item : A positional parameter cannot be found that accepts argument '/q'.
At line:1 char:19
+ Measure-Command { rm /s /q node_modules }
+                   ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Remove-Item], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand



Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 122
Ticks             : 1226067
TotalDays         : 1.41905902777778E-06
TotalHours        : 3.40574166666667E-05
TotalMinutes      : 0.002043445
TotalSeconds      : 0.1226067
TotalMilliseconds : 122.6067

@benhillis

This comment has been minimized.

Member

benhillis commented Aug 9, 2017

@thisguychris - sorry it should be "rmdir"

@thisguychris

This comment has been minimized.

thisguychris commented Aug 9, 2017

Remove-Item : A positional parameter cannot be found that accepts argument '/q'.
At line:1 char:19
+ Measure-Command { rmdir /s /q node_modules }
+                   ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Remove-Item], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand



Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 150
Ticks             : 1500664
TotalDays         : 1.73687962962963E-06
TotalHours        : 4.16851111111111E-05
TotalMinutes      : 0.00250110666666667
TotalSeconds      : 0.1500664
TotalMilliseconds : 150.0664

Still getting the error, I timed it though by checking the time. manually, its around 15seconds,

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented May 24, 2018

This was deemed fixininsiders back in Summer 2017. If there are outstanding problems, reboot under a new issue following CONTRIBUTING.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment