Hi, On Tue, 23 Mar 2010, Guido Berhoerster wrote:
I repeatedly 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 bash(1) BUGS.
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 consider.
I have anecdotal evidence that pattern matching while processing 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 work ...]
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 clean 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. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org