* Stephan Kulow
Am Dienstag 23 März 2010 schrieb Guido Berhoerster:
* Michael Matz
[2010-03-23 14:49]: 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. 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. I have anecdotal evidence that pattern matching while processing textfiles is significantly slower in bash compared to ksh93/dash.
Well, being 2.5 times slower doesn't really answer "when does it matter?". I mean how often do you need the performance of 'system' to be as high as possible when usually the thing that sh executes takes a million more time? (honest question and one you need to have prepared).
To give you an example, I use a set of scripts for monitoring on my Debian server which are, similar to Munin, executed in intervals. By explicitly using /bin/dash rather than /bin/sh which is linked to bash this cuts down the time for executing all scripts and saves a significant amount of memory. It matters where you execute scripts sequentially and I/O is not the limiting factor (e.g. the Debian boot process ;). Another area in which bash is bad at and which matters even more are subshells, for a rough estimate try time $shell -c 'i=0; while [ $i -lt 10000 ]; do $(a=$$); i=$((i+1)); done' with bash, dash, and ksh93. Here dash is 3 times faster and ksh93 37 times faster than bash (ksh93 shines here because it does not actually use a subprocess). And, as I mentioned before, being able to switch to ksh93 can yield significant further performance gains due to a number of builtins. But performance was not my only rationale.
I'm not so afraid of /bin/sh pointing to dash in the running system, what I'm mostly afraid of is switching to dash in our build system - most debian bugs are about packages breaking / changing behaviour with dash.
Yes, that is actually the only critical part as we would hav to make a switch at some point in time. However, from a quick glance at the Debian bugtracker it seems that the vast majority of problems are debian/rules files and upstream scripts and not so much the build systems (for others: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-release@lists.debian.org&tag=goal-dash gives you an overview over the issues and how Debian deals with it). Would it be possible to define an additional build target (that is an exact copy of Factory but with dash as /bin/sh) in the OBS for projects making the switch in order to ease the transition? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org