On Tue, 23 Mar 2010, Guido Berhoerster wrote:
hear this claim, seldom to be followed up by credible
numbers. And of course: when does it actually matter, even if some other
shell was faster? (I already can feel the answer being "but booting will
be so much faster then", which is wrong).
Well the "claim" acutally comes from the bash maintaines, read
That's a witty remark, not evidence.
One example is startup time, try libmicro's
system > benchmark
/usr/lib/libMicro/bin/system -E -C 200 -L -S -W -N "system" -I 1000000
with /bin/sh as a link to ksh or dash and empty .profile/ENV.
dash is 2,5 times and ksh93 is still 1,5 times faster.
Please? With -I 20000, so it takes some measurable time:
pdksh: 13.6 seconds; 13501 usecs/call
ash: 12.7 seconds; 12715 usecs/call
zsh: 11.6 seconds; 11583 usecs/call
ksh93: 3.2 seconds; 3139 usecs/call
bash: 3.1 saconds; 3176 usecs/call
That's on a 11.1 (and I don't have dash, only ash). I'm not impressed.
But the above numbers don't mean that I would be opposed to making for
instance zsh the default shell, even though it is four times slower than
bash. Simply because system(3) isn't all that important, if you're
spending more time in system(3) than in actual data processing you're
doing something wrong anyway. That doesn't mean that system(3) should be
arbitrarily slow, but it means that it's not a very large factor to
I have anecdotal evidence that pattern matching while
textfiles is significantly slower in bash compared to ksh93/dash.
Err, well, I have anectodal evidence that anecdotal evidences shouldn't be
trusted too much :)
Furthermore, ksh93 offers a lot of builtins for
standard commands which
are significantly faster than forking and execing and which could be
taken advantage of.
That is an advantage, indeed.
[... too much
It will be some work to implement this but this can take place
gradually and does not need to happen overnight.
Well, if you want to work on that, be our guest. If you can convince the
package maintainers to take patches, or upstream to integrate them (even
better) all is fine. I'm only against making it a policy, which suddenly
would force other people to invest work. That might be okay if the
advantages are large and obvious, but in this case they aren't.
Ubuntu has been using dash as /bin/sh since 2006
I trust that that one is more capable than our ash? :
% /bin/ash -c 'i=0; j=$((i+1))'
arith: syntax error: "i+1"
and Debian is preparing to do the same for Squeeze, so
a lot of the
required changes have already been incoroporated into upstram projects.
An don't forget that on Free/Net/OpenBSD /bin/sh has always been ash, on
Opensolaris /bin/sh is a linked to ksh93.
Aha. And that's relevant exactly how? After all you said you
were talking about internal scripts, not upstream ones?
For our own scripts it would only mean that we enforce
coding practices which is IMHO a good thing and it is also not
too hard, you just need test them with dash instead of bash.
See above, if you want to work on that, jolly good.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org