This is the mail archive of the
mailing list for the Cygwin project.
Re: Question about ash and getopts
- From: seebs at plethora dot net (Peter Seebach)
- To: Cygwin List <cygwin at cygwin dot com>
- Date: Mon, 29 Dec 2003 20:51:16 -0600
- Subject: Re: Question about ash and getopts
- Reply-to: seebs at plethora dot net (Peter Seebach)
In message <firstname.lastname@example.org>, Larry Hall writes:
>Would you be willing to take this a step further and provide some
>configuration timings for some of the existing Cygwin packages? Of
>particular interest would be the larger packages, like binutils, gcc, and
>gdb. If these have favorable results, I think it could spark some
Okay, here's timings for gcc. This took something over an hour of wall
clock time on the machine I'm supposed to be working on, but it's data.
The shells are:
sh-nog: /bin/sh, compiled as is; I just recompiled it to try to make sure
I had the same compiler flags.
sh-get: /bin/sh, with the "-j" taken from the getopts line in builtins.def.
pdksh/bash: As shipped with cygwin.
ash was built from "ash-20031007-1".
real 2m48.750s 2m49.258s 2m52.290s 2m47.720s
user 1m51.889s 1m51.688s 1m51.788s 1m51.959s
sys 1m40.250s 1m40.541s 1m41.481s 1m41.490s
real 2m48.437s 2m53.778s 2m47.481s 2m47.931s
user 1m51.619s 1m51.469s 1m52.299s 1m51.969s
sys 1m40.490s 1m41.641s 1m41.490s 1m40.661s
real 2m54.388s 2m49.546s 2m50.409s 2m54.558s
user 1m52.659s 1m53.868s 1m53.279s 1m52.499s
sys 1m41.321s 1m41.971s 1m42.161s 1m43.372s
real 2m53.370s 2m54.166s 3m1.676s 2m53.254s
user 1m53.439s 1m54.409s 1m54.169s 1m53.788s
sys 1m45.572s 1m44.973s 1m46.193s 1m45.994s
I do not see here any reason to believe that there's any difference, at all,
between the two versions of ash.
Furthermore, I noticed something: The existing ash is getting built with the
code for the getopts function compiled in, so the only effect "enabling" it
has is to add it to the list of shell builtins. In fact:
$ strings /bin/sh.exe | grep getopt
Usage: getopts optstring var [arg]
If we're really worried about the performance of the scan through the list
of builtins when parsing commands, the obvious thing to do would be to sort
the list lexicographically and use a binary search instead of checking all
of them. No one's ever done this, probably because there's no reason to
suspect that it would make a measurable difference.
The evidence does seem to suggest that ash may be measurably
faster than pdksh or bash, but the difference is in the area of a couple
Anyway, so far as I can tell, getopts has been in /bin/sh, just removed from
the command list, for some time. Further prodding suggests that #ifdefing
out all of the related functions may make a measurable difference in size, but
not a particularly significant one:
-rwxr-xr-x 1 Seebs None 73728 Dec 29 20:43 sh-new.exe
text data bss dec hex filename
69972 2300 3808 76080 12930 sh-new.exe
-rwxr-xr-x 1 Seebs None 74752 Dec 29 20:44 sh-get.exe
text data bss dec hex filename
70948 2300 3808 77056 12d00 sh-get.exe
In short, the 976 bytes of actual code generated are likely to require one
more 1024-block of space on disk.
The cost of a single call to an external getopt should quite thoroughly
dwarf any hypothetical cost of loading that extra block from disk, especially
given that Windows, last I heard, was smart enough to cache files which were
still being used.
It is, theoretically, possible that there exists somewhere a configure script
which is substantially impacted by this. It would need to make thousands of
calls to a shell function named "getoptz" or something similar, to maximize
the cost of string compares. (If it were an external executable, the cost
of the string compare would be lost in the noise.)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html