This is the mail archive of the 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 <>, 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".

shell: ../sh-nog
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
shell: ../sh-get
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
shell: pdksh
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
shell: bash
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:
Problem reports:

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