In message <[EMAIL PROTECTED]>, 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/
