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:
>Perhaps.  By your own admission, you used different source though so the 
>results of the space savings are inconclusive, or more precisely, 
>incompatible given the historical base.

I can't imagine that "the ash source" varies that widely.

>But I can't and won't argue you 
>did not make an effort to investigate the "space saving" claim.  However, you 
>need to be methodical and complete to make your efforts worthwhile.  If
>you can compare ash using the current sources with and without the features
>you want and prove there is no performance hit, then I'd say you have 
>something very worthwhile.  If not, at least we have some good data to
>point to, which it seems is part of your concern now.  This would be a 
>productive effort, no matter what the outcome, which is why I suggested it.
>But that doesn't mean you have to follow through obviously.

That's a good point.  I'm in the process of running Cygwin setup on my Windows
box to make sure I'm current.

>accepted.  In your case, the bar is raised rather high.  Performance of
>configure scripts was abysmal when /bin/sh == /bin/bash.  That prompted 
>the change to /bin/sh as ash.  A trimmed version of ash was introduced 
>to save more time.  The difference was noticeable.

Does anyone have the details of the results, and what trimming was involved?
There are a lot of tweakables in ash that would affect performance a
lot more than "removing getopts".

>for the better.  I don't think there will be much enthusiasm for a change
>that slows down configures (thus another reason for the suggestion I made
>about testing this with your getopts-enabled ash).  So, if you want to 
>get this feature back into Cygwin's ash, you definitely will need to show
>that it can be done without a performance penalty.

Understood.  My own inclination would be to accept a *small* performance
penalty to have a crucial shell programming feature in the shell, simply for
portability's sake.

>I think I've been pretty clear on this subject.  Unless you have a 
>specific question that I haven't already answered, I don't plan to 
>respond to further posts in this thread.  IMO, this has been discussed
>more than sufficiently and further discussion is getting more and more 
>off-topic.  For those interested in pushing for change in this area,
>it's time to do.

Fair enough.

I remain interested in any specific analysis of the effect of getopts on shell
performance at any time; so far as I can tell, that was one big streamlining
effort, and there was no per-part analysis.


Unsubscribe info:
Problem reports:

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