From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from spool.UU.NET ([153.39.3.34]) by hawkwind.utcs.toronto.edu with SMTP id <2744>; Thu, 8 Apr 1993 18:50:04 -0400
Received: from srg.UUCP by spool.UU.NET with UUCP 
	(5.61/UUNET-uucp-primary) id AA16533; Thu, 8 Apr 93 18:49:40 -0400
Received: from ceres.srg.af.mil by srg.srg.af.mil
	id aa08120; Thu, 8 Apr 93 18:31:27 EDT
From:	culliton@srg.af.mil (Tom Culliton x2278)
X-Mailer: SCO System V Mail (version 3.2)
To:	haahr@mv.us.adobe.com
Subject: Re:  Speed of rc
Cc:	rc@hawkwind.utcs.toronto.edu
Date:	Thu, 8 Apr 1993 18:31:31 -0400
Message-Id: <9304081831.aa24256@ceres.srg.af.mil>

me> When running commands or scripts it seems that rc often takes longer
me> than it should, especially compared to sh or ksh.

paul> i don't find this true at all.  i haven't ever used ksh seriously, but
paul> rc feels (that's not is, but feels) much faster than sh on all machines
paul> i've tried it on.

I've actually rewritten rc scripts for sh so that they would be used by
more of our users, and seen notable speed differences.  (I'm talking
about jobs that take minutes (in either shell) rather than seconds
here, can run up to a couple hundred lines of script and chew up whole
directory hierarchies and many megabytes of data.)  Except in cases
where rc made it easy to use a better algorithm, which created fewer
processes or invoked fewer external commands, sh wins.

There seem to be a couple of components to this.  First sh has test
builtin, and on our machines, for rc to use test means firing up sh to
do it.  Second when I use pattern matching to any significant extent,
or do lots of fiddling with lists, rc seems to bog down.  Heavy `{}
usage also seems to chew lots of time.

Don't get me wrong, this is not meant to be a criticism of rc, I love
it and wouldn't want to give it up.  It was about 10 times easier to
write the scripts in rc than it would be in sh, and they're often much
smaller and cleaner.  Using rc encourages me to write things when it
wouldn't seem worth the effort in sh or (shudder!) perl.  (I think that
Perl is exactly the wrong solution for the same reasons that PL/1 was.)

paul> the last major performance
paul> tweak that i recall was that there were some list operations being done
paul> in O(n^2) time when they didn't have to be, and that fixed, but i'm not
paul> sure if that was a pre- or post-1.4 change.

I remember this as a pre-1.4 change, but operations on big lists still
seem to take a fair amount of time.

paul> profiling code & looking for hot spots is always a good thing to do.
paul> i think you'll find that rc is pretty much flat and not spending an
paul> inordinate amount of time in any particular kind of operation.

The difference may well be simply one of usage styles, and the answer
may be as simple as some hints about how to improve the efficiency of
rc scripts.  For example using find where appropriate is usually a BIG
win especially since test isn't builtin. 

Tom

PS - I actually spent a fair amount of time once trying to figure out a
stunt to run co-processes under rc so I can fire up sh (for test), and
something else to do math, exactly once and then have functions that
talk to them.  In the end I decided it either couldn't be done or
wasn't worth the effort.