[ale] compiled system calls versus shell scripts

[Christopher Fowler]

>From the man page.  It uses -c ad the full command
on argv[2].  This forces the shell to parse it

       int my_system (const char *command) {
           int pid, status;

           if (command == 0)
               return 1;
           pid = fork();
           if (pid == -1)
               return -1;
           if (pid == 0) {
               char *argv[4];
               argv[0] = "sh";
               argv[1] = "-c";
               argv[2] = command;
               argv[3] = 0;
               execve("/bin/sh", argv, environ);
               exit(127);
           }
           do {
               if (waitpid(pid, &status, 0) == -1) {
                   if (errno != EINTR)
                       return -1;
               } else
                   return status;
           } while(1);
       }

On Thu, Oct 23, 2003 at 12:05:27PM -0400, Bjorn Dittmer-Roche wrote:
> On Wed, 22 Oct 2003, Christopher Bergeron wrote:
> 
> > Aahhh!  That explains why when I "time" each I get almost double results
> > from the compiled binary.  I created a shell script and a binary that do
> > the exact same thing and I got results that were opposite (as you
> > described) from what I expected.  For those that don't know, you can
> > "time" a command by simply running:  ' time whatever.sh ' or ' time
> > binaryfilename '.  When the program is completed, you'll be presented
> > with a timing calculation of the execution time.  As a result (of my
> > result), I decided to post this thread to the list.  Thanks for sheding
> > some light on it, Doug!!!
> 
> I believe that the system(3) call is actually quite a bit worse than what
> Doug has said. system(3) is not equivilant to one fork(2) and one exec(3),
> but something more like two of each. From the FreeBSD man page:
> 
> The system() function hands the argument string to the command inter-
> preter sh(1).
> 
> So if the command you pass to sh(1) is builtin, then, indeed, you would
> have one fork(2) and one exec(3) (although this is probably implemented in
> a slightly more efficient way using just one system call). However, most
> of the commands Christopher is talking about are NOT built in, which means
> that sh has to re-fork off another process and exec in that, giving you
> something like two forks and two execs! So you might do a bit better with
> a c program that calls fork(2) and exec(3), then one that uses system(3).
> There are also calls on many systems for forking and execing together
> which are more efficient (I believe vfork(2) is one such function). I
> would expect a c program that vforks all your commands to run slightly
> better than a shell script, but not much. The lesson here is that
> system(3) is not your friend when it comes to speed (or portability, for
> that matter).
> 
> >
> > Does anyone know how to do the Make / Makefile thing at bootup?  How
> > does one build the makefile, and where do you put it?
> 
> It is explained here:
> 
> http://www-106.ibm.com/developerworks/linux/library/l-boot.html
> 
> I have read a few of the relevant articles casually and IBM claims that
> make can be used to boot the system faster than init but I didn't see any
> actual numbers. RH says they tried it and it didn't make a big difference
> (also not giving any numbers). Weather and how much it helps probably
> depends a lot on your system configuration (that is, what services you are
> running, what kind of drives the binary's and config files live on, etc),
> but it's possible that even the best case doesn't speed things up too
> much. You could also try things like copying /bin and /etc to ramdisks,
> which would speed up reads by consolidating otherwise disparate disk
> reads. Another idea would be to increase the percieved performance by
> putting some things at the end (eg, allowing users to log on before
> everything is up and running. Some window systems do this, but I find it
> very anoying when people can't access the network until the machine
> "settles")
> 
> 
> Lots of luck!
> 
> 	bjorn
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale