Why use pwd(1) for getpwd(3C)? (Re: Why use find?)

[Conor P. Cahill]

In article <tim.655748499 at holly> tim at delluk.uucp (Tim Wright) writes:
>Well I can't speak for all System V's but all the ones I have used don't
>have /bin/pwd suid anyway so that's no excuse. It would still be *massively*
>more efficient to do the work pwd does in a library call (i.e. stat back

How do you define *massively*?  Is it really important to you that if
you ran getcwd 1,000 times in a loop that it would take much longer to 
run than if it was not a popen()?

Look at it from the system standpoint.  getcwd/getpwd are seldom used
functions, so the relative performance of the two implementations will not
have any effect on the overall system performance (or even on the overall
performance of a non-trivial application).

Here is a portion of the output from my system accounting last month:

                                     TOTAL COMMAND SUMMARY
COMMAND   NUMBER      TOTAL       TOTAL       TOTAL   MEAN    MEAN     HOG      
NAME        CMDS    KCOREMIN     CPU-MIN   REAL-MIN  SIZE-K  CPU-MIN  FACTOR   

TOTALS    646704     1876.70   2071.13    907889.81    0.91    0.00    0.00 
pwd          689        1.90      0.61         2.72    3.10    0.00    0.22

Note that only 689 pwd's were run in an entire month.  This includes
command line pwds that weren't built-in to the respective shells, all
calls to getcwd, etc.

If you were to change this so that the calls to pwd were saved by implementing
the pwd function that was soooooooo efficient that it used up zero time it
would only change the total CPU by .61 minutes (or approx .02% - that is not
a typo - the change is just 2 one-hundreds of one percent).

I wouldn't make any changes to a system for that little of a gain.
 
>up the tree), than it is to fork and exec another command ! It just looks
>like people were very lazy (it couldn't have been that difficult to copy
>the pwd code to the library).

I wouldn't say lazy.  Just realistic.  Why change something that isn't
broken?  
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170