tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mksh import

,--- You/Dennis (Thu, 6 Jan 2011 13:54:20 +0800) ----*
| If you have accounting turned on on your system 

No accounting on the FreeBSD system, for sure, and I am close to
certain about the other systems I used.

| the reason ksh93 does so well with that script becomes clear: The
| other shells all fork a bunch of subshells, I'm guessing to execute
| each instance the recursively-called function, while ksh93 manages
| to complete the whole thing in a single process (that's why the
| system time is close to zero).

Interesting -- I've never noticed that with 'bash', but I wasn't
really watching.  Later I'll run the test again with bash, monitoring
the 'bash' processes.

| That's a pretty good trick, but I'm not quite sure the numbers
| from that can be translated into an expectation for real world
| performance.  Most shell scripts I read spend most of their time
| running other programs, and if you do that here (say, change echo
| to /bin/echo) I've got a feeling the difference between that and
| /bin/sh will look considerably smaller.

That is close to the point I made early on: in a build environment,
one should expect much more time being spent compiling than spawning
the compilers.  Honestly, I can't think of a real-life case where
shell performance would matter to me; I'd never do the work similar to
what is in the test scripts we just saw, using any shell, if I cared
about the performance.

But it's a very interesting experiment -- and the portability issues
are no less interesting than the performance ones, IMHO.

| That's not to say ksh93 isn't interesting, but I don't think the
| fact that it runs that script two or three times faster than
| everything else says too much about anything beyond that script.

This is still the first good test case for shell performance I've
seen.  Interesting to me :-)


-- Alex -- --

Home | Main Index | Thread Index | Old Index