Configure script speedup due to dash for /bin/sh
Hi, I made /bin/sh point to dash instead of bash and measure how this change speeds up a few randomly picked configure scripts. The speedup achieved is: pkg-config: 2% libarchive: 3% llvm: 7% gcc: 24% coreutils: 17% openssh: 9% htop: 13% Method used: cd /some/tmpfs bsdtar xf /the/package.tar.gz time ./configure # switch /bin/sh symlink rm -rf the-extracted-package bsdtar xf /the/package.tar.gz time ./configure Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Mon, May 24, 2010 at 12:59:12PM +0200, Tilman Sauerbeck wrote:
Hi, I made /bin/sh point to dash instead of bash and measure how this change speeds up a few randomly picked configure scripts.
That looks quite noticable. My only concerns is that there are a lot of programs out, which starts shell scripts in their autoconf stuff with /bin/sh but using bash extensions instead. To get a feeling about that, I've done a complete rebuild of core in my CRUX 2.7 test-drive, but nothing failed at all :) Even not glibc, but using version 2.11.2 there. regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On Tue, May 25, 2010 at 10:37:17AM +0200, Juergen Daubert wrote:
On Mon, May 24, 2010 at 12:59:12PM +0200, Tilman Sauerbeck wrote:
Hi, I made /bin/sh point to dash instead of bash and measure how this change speeds up a few randomly picked configure scripts.
That looks quite noticable. My only concerns is that there are a lot of programs out, which starts shell scripts in their autoconf stuff with /bin/sh but using bash extensions instead. To get a feeling about that, I've done a complete rebuild of core in my CRUX 2.7 test-drive, but nothing failed at all :) Even not glibc, but using version 2.11.2 there.
I'm sorry, made a made a mistake in the first run. Actually 2 ports failed, automake and usbutils. The first is trivial because automake's configure checks for a valid shell, dash isn't one of them. The failure of usbutils is a more fragile one, because there's something wrong with the build of libusb, a dependency of usbutils. It's easy to reproduce the error: #:> ln -sf dash /bin/sh #:> prt-get update -fr libusb usbutils It works if libusb was build with bash as shell. Don't know what's going wrong here, but at all I think it's not worth to hunt bugs like that. Even though it would be nice to have the speed improvments of dash, but well ... Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Juergen Daubert [2010-05-28 11:02]:
On Tue, May 25, 2010 at 10:37:17AM +0200, Juergen Daubert wrote:
On Mon, May 24, 2010 at 12:59:12PM +0200, Tilman Sauerbeck wrote:
Hi, I made /bin/sh point to dash instead of bash and measure how this change speeds up a few randomly picked configure scripts.
That looks quite noticable. My only concerns is that there are a lot of programs out, which starts shell scripts in their autoconf stuff with /bin/sh but using bash extensions instead. To get a feeling about that, I've done a complete rebuild of core in my CRUX 2.7 test-drive, but nothing failed at all :) Even not glibc, but using version 2.11.2 there.
I'm sorry, made a made a mistake in the first run. Actually 2 ports failed, automake and usbutils. The first is trivial because automake's configure checks for a valid shell, dash isn't one of them.
The failure of usbutils is a more fragile one, because there's something wrong with the build of libusb, a dependency of usbutils. It's easy to reproduce the error:
#:> ln -sf dash /bin/sh #:> prt-get update -fr libusb usbutils
It works if libusb was build with bash as shell. Don't know what's going wrong here, but at all I think it's not worth to hunt bugs like that. Even though it would be nice to have the speed improvments of dash, but well ...
I agree. We *could* change the RC scripts to explicitly ask to be executed by dash, but I'm not sure whether it's worth it. If anyone has numbers on this I'm all ears. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
participants (2)
-
Juergen Daubert -
Tilman Sauerbeck