Mailinglist Archive: opensuse-packaging (130 mails)

[Guido Berhoerster <guido+opensuse.org@xxxxxxxxxxxxxxxx>]

* Michael Matz <matz@xxxxxxx> [2010-03-24 14:51]:
> > 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.

# /usr/lib/libMicro/bin/system -E -C 200 -L -S -W -N system -I 20000·

dash:                       1.21781s; 1200.16680 usecs/call
ash:                        2.17763s; 2145.16600 usecs/call
bash (LC_ALL=C):            3.40030s; 3354.16580 usecs/call
bash (LC_ALL=en_US.UTF-8):  5.57932s; 5506.36800 usecs/call
ksh93 (LC_ALL=C):           6.00663s; 5924.16780 usecs/call
ksh93 (LC_ALL=en_US.UTF-8): 6.17549s; 6102.36820 usecs/call

Startup time does e.g. matter for my monitoring scripts and CGI
scripts. And it is just one example, another more relevant one
which I have mentioned in this thread is subshell performance.
And finally -- performance was not my _main_ and _only_
rationale for this.

> > 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.

It also has shcomp :)

> 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.

I am interested in this or I wouldn't have brought it up here. It
could be mandatory for newly added scripts only, otherwise it
wouldn't make sense to me to fix things. Furthermore, it would
probable not be that much work for maintainers to check whether
upstream scripts work with /bin/sh when they upgrade packages and
to patch /bin/sh to /bin/bash if necessary.

> I trust that that one is more capable than our ash? :
> % /bin/ash -c 'i=0; j=$((i+1))'
> arith: syntax error: "i+1"

openSUSE ash is ancient. This and other issues have been for some
time. If you're interested in the differences, see
http://www.in-ulm.de/~mascheck/various/ash/

> > 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?

It is relevant for build systems which has been brought up here.
Debian's efforts also have resulted in changes upstream.

> > 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.

Working on it only makes sense if maintainers accept patches
for such changes.

-- 
Guido Berhoerster
-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx