Article View: comp.sys.amiga.tech
Article #1268Re: Links vs. aliases
From: Mike (I'll think of something ye...
Date: Thu, 14 Sep 1989 00:42
Date: Thu, 14 Sep 1989 00:42
42 lines
2863 bytes
2863 bytes
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
Technical Details
Message-ID:
<1989Sep14.004238.7603@agate.berkeley.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!mwmReferences:
<19644@gryphon.COM> <1989Sep9.080227.14162@agate.uucp> <2771@abaa.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!mwm From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Links vs. aliases Message-ID: <1989Sep14.004238.7603@agate.berkeley.edu> Date: 14 Sep 89 00:42:38 GMT References: <19644@gryphon.COM> <1989Sep9.080227.14162@agate.uucp> <2771@abaa.UUCP> Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44) Reply-To: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) Organization: Missionaria Phonibalonica Lines: 42