In message <[EMAIL PROTECTED]>, Shankar Unni writes:
>I guess the big question now is: how would Peter "prove" to anyone's
>liking that ash+getopts ~= ash-getopts in performance (and nowhere near
>"bash")? Is there some acceptance criterion that anyone's willing to
>spell out? PTC is fine, but it's hard to evaluate a patch unless an
>objective (or even subjective) performance criterion is spelled out..
Well, in this case, it turns out to be fairly easy to demonstrate, simply
because the ash in /bin/sh *has* the getopts code, all it's missing is the
entry in the builtin command table. Because the command table lookup only
checks string equality if first letter matches, the total code executed is
roughly
if (*a[x].string == *n && (unexecuted)
goto increment
++x;
if (x < MAX_X)
on each command hit. This is, quite clearly, lost in the noise. You can
verify this (I did) with
$ strings /bin/sh.exe | grep getopts
which prints the usage message found only in the actual getopts function.
Note also that, on the gcc configure script, the difference between /bin/sh
and bash is maybe 5 seconds on a script that takes nearly 3 minutes. It's
hard for me to imagine this being the source of the word "abysmal"; I'm
assuming something else was changed. Maybe different optimizer flags were
used on /bin/bash back then, which produced worse results?
-s
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
