🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #1268

Re: Links vs. aliases

#1268
From: Mike (I'll think of something ye...
Date: Thu, 14 Sep 1989 00:42
42 lines
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!mwm
References: <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