On 3 Aug 1996, Rob Browning wrote:
> Craig Sanders <cas@taz.net.au> writes:
>
> > what i will never understand, though, is why people use perl for
> > jobs that sh is much better suited to.
> >
> > perl is great if you want awk/sed/grep/kitchen sink all rolled into
> > one scripting language. but there's a price - perl's slower and
> > bigger and takes longer to load.
>
> What I will never understand is why people assume that perl is so much
> slower. For most things it's much faster since it doesn't have to
> launch a separate program for most operations.
sorry, my language was unclear - i implied that perl ran slower when all
i really meant was that it takes longer to load and is overkill for many
small tasks.
perl RUNS faster, that's a fact.
perl LOADS slower, that's also a fact.
perl also requires much more memory, which on a 4mb or 8mb system will
slow things down even further due to extra swapping.
therefore tiny scripts are better done in sh, which is a) smaller and
therefore loads faster, and b) almost always in memory/cache anyway.
Of course, as you say, if you need to fork sed (or whatever) many times
then perl is clearly a winner.
my basic rule of thumb is:
if the script is mostly a program launcher then use sh. otherwise
use awk or perl or whatever language best suits the application.
one big advantage to sh for me is that if i find that i am entering
similar or repetitive commands at the prompt, i can easily cut and paste
the command line into a text file. Add "#! /bin/sh", some extra line
breaks to make it more readable, some comments to explain what it does
and what arguments it takes, and i have a new script.
I'd like to see a bourne-like shell with perl-like regexp stuff (mainly
sed & grep) built in - i'd switch to that in a flash. As a built-in it
would be extremely fast, and i'd still be able to test/debug/prototype
my scripts interactively on the command line :-)
Craig