RE: Making /bin/sh == bash. Has the time come?

["Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>]

Ok, I reran the wxWidgets configure test, taking Thorsten's CONFIG_SHELL tip
into account this time:

/bin/sh = ash
=============
export CONFIG_SHELL=/bin/bash; time ./transfigure

real    3m21.888s
user    5m2.357s
sys     1m38.022s


export CONFIG_SHELL=/bin/sh; time ./transfigure

real    3m3.738s
user    5m1.330s
sys     1m28.028s

time ./transfigure   (I.e., default CONFIG_SHELL, which is empty)

real    3m35.674s
user    5m5.728s
sys     1m51.104s

/bin/sh = bash
=============

export CONFIG_SHELL=/bin/bash; time ./transfigure

real    3m35.286s
user    5m6.974s
sys     1m50.462s

export CONFIG_SHELL=/bin/sh; time ./transfigure

real    3m35.206s
user    5m5.343s
sys     1m48.977s


So:
- "transfigure" is a dead-simple shell script that just calls ./configure
with a slew of config options.
- Everything's faster today (real anyway), probably due to the following:
  - I'm probably using a different snapshot.
  - I cvs updated my wxWidgets source just before running the tests.
  - In the previous tests I wasn't particularly careful to leave the machine
alone (did some web browsing, email etc).  This time I made sure to do
nothing during the tests.
- Percentage differences between configuring with bash vs. ash:
  real:   ~+17%
  user:   ~+1%
  system: ~+25%
- Apparently the only way to get ash used at all is by explicitly "export
CONFIG_SHELL=/bin/sh"ing.  In particular note the third ash test, where
/bin/sh is ash, and yet the configure times appear to indicate that bash is
in fact being used.

Ergo:
- Yes, sh is still faster than bash.
- It's not a large enough difference that I would care about it.  Others'
mileage may perhaps vary.
- It's unclear to me that it matters in any case, since apparently
configures have been using bash anyway.
- It's unclear to me then where the "sh is ash not bash" issues are actually
coming from, if not from run-of-the-mill configures.
- If it isn't configures, does anybody actually care about the semi-minor
slowdown since it would eliminate "ash != bash" issues?

Hence:
- I still say /bin/sh == bash is the way to go.

QED.

-- 
Gary R. Van Sickle
 

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Gary R. Van Sickle
> Sent: Friday, June 10, 2005 6:14 PM
> To: cygwin@cygwin.com
> 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: cygwin-owner@cygwin.com 
> > [mailto:cygwin-owner@cygwin.com] On Behalf Of Christopher Faylor
> > Sent: Friday, June 10, 2005 10:07 AM
> > To: cygwin@cygwin.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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/