Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!whuxl!whuxlm!akgua!gatech!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: net.unix-wizards
Subject: Re: shell compiler?
Message-ID: <157@brl-smoke.ARPA>
Date: Sun, 20-Apr-86 21:19:35 EST
Article-I.D.: brl-smok.157
Posted: Sun Apr 20 21:19:35 1986
Date-Received: Thu, 24-Apr-86 06:17:02 EST
References: <96@cstvax.UUCP> <796@brahma.cs.hw.AC.UK>
Reply-To: gwyn@brl.ARPA
Organization: Ballistic Research Lab (BRL)
Lines: 18

In article <796@brahma.cs.hw.AC.UK> chris@cs.hw.AC.UK (Chris Miller) writes:
>The conclusions seem clear:
>-	The time spent in shell interpretation is negligible compared to
>	the time taken to exec other programs.
>-	Searching directories to find commands is cheap compared to
>	fork/exec, but expensive compared to interpreting shell control
>	constructs.
>-	For very small scripts, the startup time of the shell compared
>	to a C program is a significant overhead.

We have both an Adventure shell and a C shell implemented as Bourne
(SVR2) shell scripts, with acceptable performance.  The shell is
fairly well designed for its application domain (running processes
on UNIX), and having just the one program source rather than both
source and compiled version is a big win.  The shell actually
parses the script into an internal form, then acts as an interpreter;
I've written other application-specific utilities that work on the
same general principle and find that they can run pretty darn fast.