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
