On 1043533227 seconds since the Beginning of the UNIX epoch
Matthias Buelow wrote:
>

>It is very hard for me to believe what I'm seeing here, I can only 
>describe it as "bizarre"; that people are actually wasting time on 
>discussing how to micro-optimize the shell interpreter.

I do not think that you can characterise a 10% reduction in the
typical command execution path as a micro-optimisation.  Given that
so many tasks on UNIX involve /bin/sh, it seems like an important
program to optimise.

>                                                         As if it were 
>of any value if one shell executes ten thousand commands a second faster 
>than the other; it is even of no benchmark value, since you would have 
>to measure typical script workloads and not a simple loop,

So, for this ``it depends''.  On the one hand, the small loop that
I posted does not give a good indication of shell performance under
a typical workload, but on the other hand it does make a decent
stab at how much overhead the shell is causing.  If I were to
benchmark a ``typical workload'' then I would have very little idea
where the overhead came from and would not have a good idea what
was performing slowly.  I would not sell this benchmark as a measure
of system performance, but rather as a first stab at profiling how
the shell itself is performing.

>                                                           and besides, 
>if you want something fast, sh surely isn't the proper language to do 
>it!  *incredulously shaking head*

Well, in that case should I volunteer or will you to change all
number of existing utlities which call the moral equivalent of
system(3) to not invoke the shell?  The fact of the matter is that
/bin/sh is one of the most frequently executed binaries on a typical
NetBSD system.  For example, how many times do you think that
/bin/sh is invoked during a typical build?  How about when running
autoconf?  Etc, etc.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/