"Simple" but non-portable == useless.

[Dan Bernstein]

Summary: On a more normal machine (a DECsystem running Ultrix), Tom's
Perl script is 6% faster than my csh script. However, it uses four times
as much memory, six times as much I/O, and more page faults. Furthermore,
where my script is just one line with six simple tools piped together,
Tom's original script has 28 lines of code, and his most condensed (and
hence incomprehensible) version is still 5 lines of code. Furthermore,
Tom's script does not solve the problem as *he* stated it; my script
does.

So: Is it worth several times more space and several times more
programmer effort to get a 6% speedup (and fail to solve the problem)?
I think not.

In article <1991Feb01.180524.26619 at convex.com> tchrist at convex.COM (Tom Christiansen) writes:
> Ok, here are the problems with the Dan's latest round of pipes:
> 1) It runs considerably slower (percentage-wise) than the perl version 
>    in both system and user times.

Tom, your Convex is hardly the generic benchmark machine, and you're
cheating by not pointing out memory use. Here are times from a
DECsystem-5820 running Ultrix 4.0.

  Tom's Perl version: 2.3u 3.8s 0:20 30% 279+267k 166+25io 6pf+0w
  My csh version: 2.1u 4.6s 0:06 100% 74+104k 0+34io 5pf+0w

A Sun produces similar results.

Well, folks, look at those times. Tom's Perl version does run faster
overall---0.4 seconds out of 6.7, a 6% difference. It also uses four
times as much memory, six times as much I/O, and more page faults.

Tom, you're also ignoring the most basic human engineering factors. My
shell script is ONE LINE: one TRIVIAL line, with six obvious tools piped
together in sequence. Your shortest Perl version has FIVE lines packed
with unobvious, unreadable tricks and no obvious data flow; your
shortest readable version has TWENTY-EIGHT lines of code. The shell
script is trivial to write, trivial to maintain, and trivial to
understand. The same cannot be said of your Perl versions. Sorry for
shouting, but you keep ignoring this issue.

Okay, folks, we have two scripts that do basically the same job. One of
them runs 6% faster, but is five times longer and uses about four times
more memory. How much memory do you have on your machine? Can you spare
four times your old memory use? Are you willing to write one fifth as
many programs just to get a 6% speed improvement? Are you sure that
speed improvement will remain when you're swapping every two seconds?

> 2) It doesn't list where the collisions occur, which 
>    was, after all, my goal in writing it in the first place.

BIG FUCKING DEAL. Your stupid script puts in all sorts of extra garbage,
which is against every principle of tool design. You have ``which'';
learn to use it. Learn to write code once instead of copying it into
every single new program.

> 3) It screws up on pathological filenames.

I addressed this at length in another posting, which you missed since
you and your kill file have been acting so manly.

> 4) It gets some things truly wrong: 
>    6 -rwxr--r--  1 tchrist      4542 Mar  4  1990 /mnt/tchrist/scripts/errlogd
>    6 -rwxr--r--  1 root         4865 Nov 19 16:58 /usr/adm/bin/errlogd
>    There's no collision there -- I can't execute the one in /usr/adm/bin
>    even with that in my path.  Dan's version thinks I can, whereas mine 
>    and Randal's and Chip's all know better.

I dispute that claim. When you say ``duplicate filenames of different
executables in PATH,'' the average admin expects a useful list,
something that might point out problems or inconsistencies in the
system. Should this list depend on which user happens to execute it (or
on which directory he happens to be in)? I think not, for the same
reason that I don't like ``which'' output relative to the current
directory---really for the same reason that I don't like the
system-level concept of a single current working directory. To put it
simply: The problem statement doesn't depend on the current user, so the
solution shouldn't either.

Now I know you prefer to be literal rather than sensible when being
sensible would lose an argument. But if we take your original problem
definition, YOUR script is truly WRONG. YOU defined the problem as only
talking about ``executables,'' not ``things that the current user can
execute.'' /usr/adm/bin/errlogd is an executable, whether you can
execute it or not.

---Dan