mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (09/09/89)
In article <19644@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes:
<Links still don't work as very good aliases,
This is the most cogent statement on the subject yet. The converse is
also true - aliases don't make very good links.
Links don't make good aliases because aliases can supply arguments or
flags; using links to do that requires changing the program (Dave
mentioned this).
Aliases don't make good links because links provide a new name for a
file in the file system. This will be visible from inside of programs
- for instance, if provided on an arg line.
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.).
<mike
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, mwm@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. mwm@ucbjade.BITNETesker@abaa.uucp (Lawrence Esker) (09/12/89)
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
esker@abaa.uucp (Lawrence Esker) (09/12/89)
In article <2771@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes:
< [stuff]
<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.
< [more stuff]
OOPS, the last line was supposed to say "... take more time than memory
resident table lookup."mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (09/14/89)
In article <2771@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes: <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. The case you described here is a soft link. <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. This is a hard link - which was what I specified. You'll also note that soft links are listed as one of the things that could cause aliases to be faster. <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. This is true - if you actually have to load the file. A well-run Unix system will have most of the blocks for common commands either loaded (because it's a shared segment), or in the buffer cache. Even then, the overhead for alias expansion (unless you have lots of them, so that the search time is non-trivial) will be neglible. <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays mwm@berkeley.edu Around in the clouds in a happy daze ucbvax!mwm In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
usenet@cps3xx.UUCP (Usenet file owner) (09/14/89)
><>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 Not to flame anybody in particular, but what difference does it make if it take .025sec or .25sec or whatever? Links or aliases would certainly be handy, but their use would be relatively rare, compared to non-linked files. REAL NAME: Joe Porkka jap@frith.egr.msu.edu
ddave@pnet02.gryphon.com (David Donley) (09/15/89)
usenet@cps3xx.UUCP (Usenet file owner) 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 > >Not to flame anybody in particular, but what difference does it make >if it take .025sec or .25sec or whatever? > >Links or aliases would certainly be handy, but their >use would be relatively rare, compared to non-linked files. > >REAL NAME: Joe Porkka jap@frith.egr.msu.edu Symbolic links would be nice for floppy users, they could put 10 megs on one disk that linked to a bunch of other disks... :-) ---- Call Bug Eyes BBS (Yes, it's back up) at (213) 372-4494
shadow@pawl.rpi.edu (Deven T. Corzine) (09/15/89)
On 12 Sep 89 15:41:30 GMT, esker@abaa.uucp (Lawrence Esker) said: esker> A hard link involves the disk controller to read an extra esker> sector that points to the real file (or is this a soft link, I esker> sometimes confuse them). In any case, extra disk accesses are esker> certainly going to take more time than links. esker> OOPS, the last line was supposed to say "... take more time esker> than memory resident table lookup." Either way, you're wrong. A hard link to a file is absolutely indistinguishable from the original file. Both are directory entries pointing to an inode which points to the data sectors. With a hard link, the directory entries point to the SAME inode. Thus, a hard-linked file takes EXACTLY the same amount of time to resolve as the original file. (Exceptions being when they arre in different directories; a deeper-buried directory entry will, of course, take extra time to access.) for two files in the same directory linked together, such as compress and uncompress, they will take the same amount of time, while the alias lookup WOULD add time, needing not only the single directory->inode->data resolution, but the memory resident table lookup as well. That is why an alias gains you nothing over a hard-linked file in terms of speed. And the purposes served remain different. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.