🚀 go-pugleaf

In article <1989Sep9.080227.14162@agate.uucp> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:

>As for speed - an alias will almost always be slower than a (hard)
>link when they do the same thing. This is because invoking the alias
>will cause all the work that invoking the link would, plus having to
>do the alias replacement. Of course, implementation details can change
>this (i.e. - linear search of an alias list, intead of something
>intelligent; aliases that are absolute path names; so many links that
>the directory adds blocks, soft links instead of hard, etc.).

Well this statement is a little hard to swallow.  Alias's are stored in memory
when they are assigned and table lookup on memory lists would be very quick.
A hard link involves the disk controller to read an extra sector that points
to the real file (or is this a soft link, I sometimes confuse them).  In any
case, extra disk accesses are certainly going to take more time than links.

However, it might be possible to make the block for the link point to the
contents of the file and not the file header.  In this case the total number
of blocks read would be the same as the original file, making it faster than
alias's.

Considering the time spent to load a file, all this discussion on speed
differences is really a moot point.  No user would notice the difference.

The rest of Mike's article points out that aliases and link are very
different and used in different applications and I think we must all agree on
this point.
--
---------- Lawrence W. Esker ----------  Modern Amish: Thou shalt not need any
                                         computer that is not IBM compatible.
UseNet Path: __!mailrus!sharkey!itivax!abaa!esker  ==  esker@abaa.UUCP