Mail Archives: cygwin/2003/12/29/17:29:12
In message <6 DOT 0 DOT 1 DOT 1 DOT 0 DOT 20031229161810 DOT 03bbd940 AT 127 DOT 0 DOT 0 DOT 1>, 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.
-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/
- Raw text -