Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <200312300251.hBU2pGqd028721@guild.plethora.net> From: seebs AT plethora DOT net (Peter Seebach) Reply-To: seebs AT plethora DOT net (Peter Seebach) To: Cygwin List Subject: Re: Question about ash and getopts In-reply-to: Your message of "Mon, 29 Dec 2003 19:18:23 EST." <6.0.1.1.0.20031229191157.03bc6bd0@127.0.0.1> Date: Mon, 29 Dec 2003 20:51:16 -0600 X-IsSubscribed: yes In message <6 DOT 0 DOT 1 DOT 1 DOT 0 DOT 20031229191157 DOT 03bc6bd0 AT 127 DOT 0 DOT 0 DOT 1>, 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 >interest. 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 percent. 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.) -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/