Edward Pilatowicz wrote:
afaik, alan was _explicitly_ testing the non-builtin case, since shell scripts are not the only commands that are becoming ksh93 wrappers.
Yes, exactly so.
also, specifically focusing on sleep in misleading, since it is not actually a perf sensitive path. bugs 5019961 and 6210677 were improved the performance or true/false and basename/dirname respectively. these are commonly used outside of shell scripts by things like makefiles. so if they were to become ksh93 wrappers (which afaik, there is currently no proposal todo), then a similar performance drop to what we're seeing with a non-builtin invocation of "sleep 0" might apply to these other commands.
Yes, that's the point I was trying to make - the justifications I've seen so far for replacing sleep with a ksh93 script was that it supported fractional seconds, and it was less code to support. However they don't seem entirely sufficient as the compatibility goal hasn't been fully defined and the amount of code saved didn't seem particularly stunning. Against that it appeared that there had been no evaluation of the potential performance impact - if there had it would seem likely that the ~ and .path issues might have been picked up, as they were clear from even a fairly cursory truss.
Therefore, when considering the more general strategy that seemed to behind this change - using ksh93 builtins to replace binary commands - it is important to consider *all* the potential impacts, as illustrated in part by the justification for 5019961 and 6210677. The other factor that needs considering is that any commands replaced with ksh93 builtins will have ksh93 semantics. which may or may not be the best choice.
that said, that doesn't mean that these binaries can't be replaced with ksh93 builtin wrappers. it just means that performance evaluations and possible performance improvements in ksh93 would need to be done before this transition could happen.
Exactly - as we both said, sleep isn't exactly performance-critical, and with the forthcoming changes to ksh to fix the issues previously discussed, it should be even faster still.
i think the take away from alan's email is simply that as commands are replaced with ksh93 wrappers, attention needs to be paid to performance so that we don't accidently introduce performance regressions for non-builtin commands.
Yes. -- Alan Burlison -- _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
