From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 11:45:31 -0400 Received: by mod.civil.su.oz.au id <28689>; Sat, 10 Apr 1993 01:45:09 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Fri, 9 Apr 1993 11:23:00 -0400 To: The rc Mailing List Subject: Re: Speed of rc In-Reply-To: <93Apr8.203942edt.2538@groucho.cs.psu.edu> Message-ID: <199304100123.13535.rc.bagir@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ 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.