This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about ash and getopts


In message <bt02b2$id8$1@sea.gmane.org>, 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]