From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 15 Apr 1993 17:07:03 -0400
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA10808; Thu, 15 Apr 93 17:06:50 -0400
Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 163721.18631; Thu, 15 Apr 1993 16:37:21 EDT
Received: from ceres.srg.af.mil by srg.srg.af.mil
	id aa10553; Thu, 15 Apr 93 16:25:51 EDT
From:	culliton@srg.af.mil (Tom Culliton x2278)
X-Mailer: SCO System V Mail (version 3.2)
To:	byron@netapp.com, john@civil.su.oz.au
Subject: Re: speed of rc
Cc:	rc@hawkwind.utcs.toronto.edu
Date:	Thu, 15 Apr 1993 16:26:45 -0400
Message-Id: <9304151626.aa12954@ceres.srg.af.mil>

Since I started this thread I wanted stop for a moment to agree whole
heartedly with John in praise of rc.  My experience is that Byron's rc
is completely stable, bug free, solid as a rock, easily ported, clean,
polished, a pleasure to use, etc.  My comments definitely fall into the
category of nitpicking. I've pushed it in all sorts of strange and
intresting ways, and (aside from a porting bug caused by SCO's flakey
signal.h) never had it fail.  Byron has nothing to apologize for and a
great deal to be very proud of.

To Byron in particular: The design philosophy behind rc has my
strongest endorsement, perl is a monster, and like one of those "all in
one" kitchen gadgets I find it completely useless.  It is unstable and
buggy, takes forever to port, and otherwise generally makes my head
ache.  My concerns about the speed of rc come from trying to do big
production type jobs with it and trying to evangelize to the unwashed
sh/csh types around here.  (Our sysadmins can't even be bothered to
support bash, and do ksh only grudgingly.  Since rc is simple enough
for anyone to understand and bug free, it would be a perfect solution,
if I could only overcome peoples inertia.)

Byron's point about analyzing rc with prof is well taken, there are a
couple of gotchas to beware of though.  People often make to much of
flattening out the usage peaks.  A high peak doesn't necessarily mean
that means that a certain section of code is a bottle neck, it could
mean the code is optimal and efficiently doing it's work in a tight
loop. (e.g. A document format to format translator that spends 95% of
it's time in 5 lines of code that handle normal text.)  Nor does a flat
profile means that the code is optimal, it could very well mean that
lots of code extra code is getting executed. (e.g. In the translator
mentioned above doing character by character i/o rather than buffered.)
And when a program is system call bound, as Byron indicates is the case
with rc, there is still the possibility of extraneous calls. (such as
the stat call that Dave Mason and Byron mention)

Dave Mason also makes an excellent point about the size of the
environment under rc and the effect on the cost of execs.  Writing in
rc it is often natural to stick things into lists in the enviroment,
which would be in a file or pipe under sh.  Especially when trying to
avoid external programs for the sake of speed.  The fact that all
variables and functions are exported adds to this.  It wouldn't suprise
me if this was were part of my time was going under SCO ODT.  A good
thing to remember when writing scripts.

Remember, I'm not throwing stones here, just asking a question: What
can we do (if anything, and short of polluting rc with extra builtins)
to speed rc up?

Tom

PS - sorry this was so long...