Re: [crux-devel] Configure script speedup due to dash for /bin/sh
On Monday 24 May 2010 7:59:12 pm 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.
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
I've always thought that having sh point to bash could be a waste of resources (cpu and/or memory), but never cared enough to quantify it, although for some time I was using tcsh instead of bash. In my experience there are too many shellscripts out there that start with #!/bin/sh and then expect bash features. I think your findings might be affected by caching, did you take that into consideration? Alan
Alan [2010-05-24 20:55]:
On Monday 24 May 2010 7:59:12 pm 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.
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
[...] In my experience there are too many shellscripts out there that start with #!/bin/sh and then expect bash features.
They can probably be fixed :p
I think your findings might be affected by caching, did you take that into consideration?
I removed the extracted directory each time before doing another configure run. That should have taken care of caching effects I think. 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?
* Tilman Sauerbeck (tilman@crux.nu) wrote:
(...)
I think your findings might be affected by caching, did you take that into consideration?
I removed the extracted directory each time before doing another configure run. That should have taken care of caching effects I think.
Running this thing in /tmp (i.e. tmpfs) should be just fine. You can always run something like sudo su -c 'echo 3 > /proc/sys/vm/drop_caches' prior configure. Alas, glibc won't build for me if dash is linked to /bin/sh, maybe someone can reproduce this behaviour as I don't think this issue is related to my architecture (x86_64) or gcc version (4.5.0) as the build works just fine with bash as /bin/sh. regards, Thomas -- Someone has messed up the kernel pointers
Thomas Penteker [2010-05-24 14:54]:
* Tilman Sauerbeck (tilman@crux.nu) wrote:
(...)
I think your findings might be affected by caching, did you take that into consideration?
I removed the extracted directory each time before doing another configure run. That should have taken care of caching effects I think.
Running this thing in /tmp (i.e. tmpfs) should be just fine. You can always run something like sudo su -c 'echo 3 > /proc/sys/vm/drop_caches' prior configure.
Yeah, but since you may not run ./configure twice in a row (autoconf caches test results itself, too!) in this case I decided to just wipe the whole thing :]
Alas, glibc won't build for me if dash is linked to /bin/sh, maybe someone can reproduce this behaviour as I don't think this issue is related to my architecture (x86_64) or gcc version (4.5.0) as the build works just fine with bash as /bin/sh.
Too bad :( 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 (3)
-
Alan -
Thomas Penteker -
Tilman Sauerbeck