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 <3D848382FB72E249812901444C6BDB1DE4DFAF@exchange.timesys.com>, "Robb
, Sam" writes:
>> Well, first off, I've done the obvious test, and verified 
>> that there is no "13k space saving".  There might be 1/2k.

>There is no 13k space saving *now*.  There may well have
>been with a previous set of sources and build tools.

I don't think there's any way that the getopts code in and of itself could
ever have been 13k.

>> I can indeed run tests, but right now, no one has offered 
>> even a TINY SHRED of actual evidence that the current broken
>> behavior ever saved any space or time.

>Immaterial, unless you think you somehow deserve an apology?

It's material to the question of whether or not we need any evidence to
justify complying with POSIX.

>  "It was the slowness of configure scripts that prompted the
>   streamlining of Cygwin's ash."

>Larry's been around and involved in Cygwin for a good while, so
>unless someone else can present some information that contradicts
>his statement, I'm inclined to take his word on the matter.

What's missing here is any evidence that removing getopts had any measurable
effect on performance.  A 13k space saving might.

>  (a) Show that ash without getopt no longer results in a
>      significant space savings (which you've already done)

Okay.

>  (b) Show that ash + getopt no longer results in configure
>      script slowness (yet to be done)

But no one has ever shown that it *did* result in configure script slowness.

The best available theory is that 13k represents a number of modifications,
some of which had measurable effects.

>  (c) Contingent on (a) and (b), submit a patch to the ash
>      maintainer that re-enables getopt in ash

I assume you mean the person maintaining cygwin's port of ash?

>Providing a patch and data showing that there's no regression
>to the slow-configure-script issue will probably significantly
>increase the chance of the problem being addressed.

Fair enough.  That said, the patch is probably already there.

>Maybe I'm naieve; but my thought is that at some point, people
>who knew what they were doing made the decision that removing
>getopt support from ash as a Good Thing.

It's entirely possible.  On the other hand, we have no data showing any
connection between getopts support and performance.

>While I have come to know and respect the people who apparently
>made this decision, I have no idea who you are.

I'm mostly a C programmer.

>You've gained some measure of credibility by bringing up the issue,
>and doing some simple experimentation to prove your point.  It's a
>shame that there is an increasingly shrill tone in your messages that
>is swamping out your more reasoned arguments.

Well, the second aspect of my hobbies that's figuring into this is that
I'm involved in standardization efforts, and I really, really, dislike
seeing a standard abrogated without solid reasons.

Anyway, I'll see about doing some testing.  If anyone could point me at
notes on the original streamlining work, and what changes were made, I'd be
very interested.  My experience leads me to believe that it is essentially
unreasonable to imagine that removing a single small shell builtin would have
a measurable performance impact; I'd be much more open to the idea that
removing a handful of things all at once would have such an impact.

-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]