rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: culliton@srg.af.mil (Tom Culliton x2278)
To: haahr@mv.us.adobe.com
Cc: rc@hawkwind.utcs.toronto.edu
Subject: Re:  Speed of rc
Date: Thu, 8 Apr 1993 18:31:31 -0400	[thread overview]
Message-ID: <9304081831.aa24256@ceres.srg.af.mil> (raw)

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.


             reply	other threads:[~1993-04-08 22:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-04-08 22:31 Tom Culliton x2278 [this message]
1993-04-09  0:38 ` Scott Schwartz
1993-04-09 15:23   ` John Mackin
1993-04-13 19:26     ` Chris Siebenmann
1993-04-13 21:13       ` John Mackin
1993-04-09 16:32   ` Dave Mason
1993-04-09 16:39     ` John Mackin
1993-04-09 19:22       ` Dave Mason
1993-04-09 21:12         ` Chris Siebenmann
  -- strict thread matches above, loose matches on Subject: below --
1993-04-15 20:26 speed " Tom Culliton x2278
1993-04-13 20:26 Byron Rakitzis
1993-04-13 21:23 ` John Mackin
1993-04-13 23:42   ` mycroft
1993-04-12  5:51 Speed " Paul Haahr
1993-04-09 15:58 Tom Culliton x2278
1993-04-08 23:09 Paul Haahr
1993-04-08 20:14 Byron Rakitzis
1993-04-08 15:45 Paul Haahr
1993-04-07 19:50 Tom Culliton x2278

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9304081831.aa24256@ceres.srg.af.mil \
    --to=culliton@srg.af.mil \
    --cc=haahr@mv.us.adobe.com \
    --cc=rc@hawkwind.utcs.toronto.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).