Re: Speed of rc

[John (Most modern computers would break if you stood on them) Mackin <john@ civil.su.oz.au>]

Here are a few comments on the speed of rc.  I hope they're not too
incoherent, but it's now or never.

Someone said that they had a problem in that their test command was
built into sh, and that therefore every time they wanted to do a test
inside an rc script they ended up having to fire up an sh to do it.
I'm sure you can do much better than that.  I have encountered that
situation on various different Unix machines (sorry, in my current
state of mind the details escape me).  There _are_ machines where
the _only_ test command is built into some flavour of sh; I think
some versions of RS/6000 AIX may be like that.  There are also
machines where, yes, test is built into sh, but a test binary
is also supplied (looking for a binary named "[" can often win).
On these latter machines, clearly the problem is solved, just use
the supplied test binary.  On machines where there really and
definitely isn't a binary for test, just compile one.  I
am sure there are sources floating around on the net.  If all
else fails there is certainly a gnu version.  That way you will
end up with a much lighter-weight operation than having to start
up a copy of sh just to do "test".  Hell if it came to that, anyone
around here could code up test.c in short order.

Now for my personal experiences and some numbers.  I have always found
rc to be acceptably fast with one exception.  When I am coding shell
scripts I am not looking for blazing performance.  It always seems to
deliver the goods, sometimes even faster than I expected.  The exception
is this.  I use a mail system called "mace" written by Boyd Roberts.  It
is a little bit like MH in that you incorporate your mail into an
inbound mail folder.  He has a facility where as the mail is incorporated,
each item's headers can optionally be matched against some REs and if
they match, a command is queued up to be executed on that mail item
after the incorporation is complete.  I am on a fairly high-volume
mailing list where it is not uncommon for thirty or forty items to
arrive while I am away from my terminal (should I not come in for
a whole weekend, I usually see hundreds).  I have it set up to
automatically move these items to the correct box, so one command
gets executed per item at the end of the incorporation.  This takes
an excruciatingly long time if there are a lot to move.  There are,
of course, many variables and it is hard to measure.  What Boyd does
is fire up a single copy of $SHELL (rc in my case) and send all the
commands down a pipe to its standard input; clearly a better idea
than one shell per command.  So I just did some simple measurements
on that.  In /tmp, I created an executable called "xx" which was just
the null C program.  I created "pus" which had 1000 lines, each saying
"xx".  I got some interesting numbers.  (This is on a DECstation 5000/120
running Ultrix 4.2, so sh is a very old version.)

: mod;; /bin/time sh -c 'cat pus | sh'
       27.8 real         5.2 user        21.1 sys  
: mod;; /bin/time sh -c 'cat pus | sh'
       27.2 real         5.3 user        20.8 sys  
: mod;; /bin/time sh -c 'cat pus | sh'
       27.5 real         5.3 user        21.0 sys  
: mod;; /bin/time sh -c 'cat pus | sh'
       27.3 real         5.4 user        20.7 sys  
: mod;; /bin/time sh -c 'cat pus | rc'
       34.7 real         1.8 user        31.3 sys  
: mod;; /bin/time sh -c 'cat pus | rc'
       34.8 real         1.8 user        31.1 sys  
: mod;; /bin/time sh -c 'cat pus | rc'
       34.5 real         1.7 user        31.1 sys  
: mod;; /bin/time sh -c 'cat pus | rc'
       34.8 real         1.8 user        31.3 sys  

I wish I had time to find out why rc used a whole third more system time.
I suspect this might be at the root of my mace performance problem.
I thought initally that it might be something to do with path searching,
so I tried cutting that out of the picture, to no obvious effect: "pus2"
contained lines with "./xx", and "pus3" lines with "/tmp/xx".

: mod;; /bin/time sh -c 'cat pus2 | sh'
       27.1 real         5.2 user        20.5 sys  
: mod;; /bin/time sh -c 'cat pus2 | sh'
       27.0 real         5.2 user        20.5 sys  
: mod;; /bin/time sh -c 'cat pus2 | sh'
       27.5 real         5.3 user        20.8 sys  
: mod;; /bin/time sh -c 'cat pus2 | rc' 
       33.7 real         1.6 user        30.5 sys  
: mod;; /bin/time sh -c 'cat pus2 | rc' 
       37.3 real         1.6 user        31.7 sys  
: mod;; /bin/time sh -c 'cat pus2 | rc' 
       35.5 real         1.5 user        31.5 sys  


: mod;; /bin/time sh -c 'cat pus3 | sh'
       27.7 real         5.3 user        21.2 sys  
: mod;; /bin/time sh -c 'cat pus3 | sh'
       27.5 real         5.3 user        20.8 sys  
: mod;; /bin/time sh -c 'cat pus3 | sh'
       27.9 real         5.4 user        21.1 sys  
: mod;; /bin/time sh -c 'cat pus3 | rc'
       34.6 real         1.7 user        31.3 sys  
: mod;; /bin/time sh -c 'cat pus3 | rc'
       34.8 real         1.8 user        31.2 sys  
: mod;; /bin/time sh -c 'cat pus3 | rc'
       34.3 real         1.6 user        31.0 sys  

As you can see, the results are substantially the same.  Note that rc
wins on user time, which is why it isn't drastically slower overall.

Maybe someone will be inspired to look at this further.  I would, and
I still might, but certainly not now and I don't know if I will get a
chance.

OK,
John.