hey bruno, afaik, alan was _explicitly_ testing the non-builtin case, since shell scripts are not the only commands that are becoming ksh93 wrappers.
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. 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. 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. ed On Sun, Feb 22, 2009 at 05:48:34PM +0100, Bruno Jargot wrote: > The benchmark is wrong: > /bin/ptime starts a new process and the shell can't use its built in commands. > > sleep built in > % ptime ksh93 -c 'i=0 ; while [[ $i -lt 10000 ]] ; do sleep 0 ; let i++ ; > done' > > real 0.076257622 > user 0.070381736 > sys 0.004646904 > > Old sleep on B99: > % ptime ksh93 -c 'i=0 ; while [[ $i -lt 10000 ]] ; do /bin/sleep 0 ; > let i++ ; done' > > real 30.481728193 > user 11.656788038 > sys 16.281711048 > > GNU sleep > % ptime ksh93 -c 'i=0 ; while [[ $i -lt 10000 ]] ; do > /usr/gnu/bin/sleep 0 ; let i++ ; done' > > real 39.264469018 > user 16.814216911 > sys 20.484500386 > > New ksh93 /bin/sleep: > % ptime ksh93 -c 'i=0 ; while [[ $i -lt 10000 ]] ; do /bin/sleep 0 ; > let i++ ; done' > > real 24.831689851 > user 8.932579241 > sys 13.592960088 > > ksh93 is /bin/sh on Opensolaris and more built in commands make system > scripts faster. Firefox configure.in runs 14 times faster on > Opensolaris because ksh93 is now /bin/sh. > > Bruno > > On 2/20/09, Alan Burlison <alan.burli...@sun.com> wrote: > > Jason King wrote: > > > > > > > Is there actual proof that they are slower? I believe the desired > > > result is that they will be binaries that use libast. If however you > > > are using sh/ksh, the idea is to trigger the builtin (since the code > > > is already mapped in -- save the fork/exec). If using something > > > else, you'll have the fork/exec old or new, and while it does mean > > > that libast must be loaded and linked, it's about the same size as > > > libc, and total we're talking about an additional 1.5mb being mapped > > > in (of which a decent amount is likely going to already be cached > > > given that there's so many things in OpenSolaris today that use ksh). > > > > > > > (running bash) > > > > elpaso$ ptime /bin/sleep 0 > > real 0.019972439 > > user 0.002685874 > > sys 0.009258688 > > > > (running ksh93) > > > > elpaso$ ptime /bin/sleep 0 > > real 0.015434806 > > user 0.002467390 > > sys 0.008352437 > > > > (running ksh93 with old C sleep executable) > > > > elpaso$ ptime /tmp/sleep 0 > > > > real 0.005872245 > > user 0.000504560 > > sys 0.003777314 > > > > So it appears that in terms of elapsed time the old C binary is ~ 2.5x > > faster than the 'new new' mechanism, when not run as a ksh93 builtin. I > > realise that sleep isn't performance-critical, and that some of the > > difference is probably due to the .path and ~ lookups that have already been > > mentioned. It will be interesting to see what difference the forthcoming > > ksh93 fixes make. > > > > -- > > Alan Burlison > > -- > > > > _______________________________________________ > > tools-discuss mailing list > > tools-discuss@opensolaris.org > > > _______________________________________________ > tools-discuss mailing list > tools-discuss@opensolaris.org _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
