Making /bin/sh == bash. Has the time come?
Gary R. Van Sickle
Sat Jun 11 00:38:00 GMT 2005
I was as surprised as the Gentle Reader was at the closeness of these
results, so I repeated this test several times. I made absolutely sure I
was running the sh I thought I was running, and the results are 100%
repeatable; there is simply no real difference in speed between shells. So
the conclusion we must jump to is that, at least on a machine as awesome as
mine, the shell used as /bin/sh is not a bottleneck.
Gary R. Van Sickle
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Gary R. Van Sickle
> Sent: Friday, June 10, 2005 6:14 PM
> To: firstname.lastname@example.org
> Subject: RE: Making /bin/sh == bash. Has the time come?
> Configuring wxWindows from cvs, on a 3.4GHz P4:
> Sh = Ash:
> real 3m55.351s
> user 5m8.610s
> sys 1m53.240s
> Sh = Bash:
> real 3m41.850s
> user 5m6.220s
> sys 1m53.426s
> Looks like the time has come.
> Gary R. Van Sickle
> > -----Original Message-----
> > From: email@example.com
> > [mailto:firstname.lastname@example.org] On Behalf Of Christopher Faylor
> > Sent: Friday, June 10, 2005 10:07 AM
> > To: email@example.com
> > Subject: Making /bin/sh == bash. Has the time come?
> > A long time ago, in a Cygwin release prior to B20.1, someone
> > made the decision to use "ash" as the standard /bin/sh for
> > Cygwin. The sole reason for doing this was that ash was
> > faster than bash.
> > Later, at one point, I implemented a sorta-wannabe version of
> > vfork, and commissioned one of the people who worked for me
> > to modify ash to use vfork. This made ash even faster than
> > it was before.
> > Recently, after too many hours hacking at vfork corner cases,
> > I came to the conclusion that getting vfork working correctly
> > was too difficult so, I turned off vfork in cygwin and asked
> > Corinna to modify ash to use /bin/sh again.
> > So, that leaves us with an ash which is still faster. For example:
> > e:\>time ash -c "i=0; while [ $i -lt 1000 ]; do i=$(expr $i
> > + 1); done"
> > 32.24user 9.72system 0:12.85elapsed 326%CPU
> > (0avgtext+0avgdata 11677696maxresident)k
> > 0inputs+0outputs (730699major+0minor)pagefaults 0swaps
> > e:\>time bash -c "i=0; while [ $i -lt 1000 ]; do i=$(expr
> > $i + 1); done"
> > 49.86user 16.51system 0:23.04elapsed 288%CPU
> > (0avgtext+0avgdata 20525056maxresident)k
> > 0inputs+0outputs (1284873major+0minor)pagefaults 0swaps
> > i.e., bash is twice as slow as ash. However:
> > e:\>time bash -c "i=0; while [ $i -lt 1000 ]; do i=$(($i +
> > 1)); done"
> > 0.14user 0.01system 0:00.15elapsed 101%CPU
> > (0avgtext+0avgdata 15712maxresident)k
> > 0inputs+0outputs (982major+0minor)pagefaults 0swaps
> > So, there are some constructs available in bash which, if you
> > assume that bash == /bin/sh, will result in much faster shell
> > script execution.
> > And, anyone who reads this list regularly will know that we
> > get a lot of complaints about the differences between bash
> > and ash, which cause people to eventually copy bash to /bin/sh.
> > So, in conversation with Corinna, I think that we're starting
> > to lean towards making /bin/sh == bash sometime soon. We
> > won't get rid of ash and will point to it when people send
> > the inevitable "Cygwin is slow!"
> > message here.
> > I was thinking that we should have something like linux's
> > "alternatives"
> > command which would allow us to set up /bin/sh to whatever a
> > user decides is best for them, defaulting to /bin/bash. This
> > is, of course, trickier to do right on cygwin since you can't
> > use a cygwin symbolic link to do a 'ln -s /bin/bash /bin/sh'
> > but you could still do something with a copy, recording
> > preferences in a file.
> > Anyway, I wanted to get people's feelings on making this
> > change. Is anyone actually relying on ash for some reason?
> > cgf
> > --
> > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> > Problem reports: http://cygwin.com/problems.html
> > Documentation: http://cygwin.com/docs.html
> > FAQ: http://cygwin.com/faq/
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Problem reports: http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin