🚀 go-pugleaf

> 
>>	In the short time that I had the use of an ST, I also noticed the
>>poor disk I/O.
> 
>    Here's were partisanship rears it's ugly head.  In the short time I used
> an Amiga, I was absolutely astounded at how long it took to put a disk
> directory up on the screen-- each silly icon (they're silly on the ST, too)
> took *seconds* to appear!  TOS may have slow disk I/O, but I'm not sure I'd
> trade it for slow file seek time.  Figure out how many files need opening
> during a standard C compile/link cycle, and you may be able to appreciate
> the problem.

*DISCLAIMER* This is intended only as a point of clarification on the Amiga
DOS structure, not in any way as an attempt to start even the sligtest battle!

Anyway, the above paragraph discussing both file seek times and directory 
times has a few problems.  First of all, directories on an Amiga are the
absolute slowest part of the DOS, no questions about it.  The reason behind
this is, obviously, the way the files are stored under the directories.  Each
directory contains its own name, some accounting data, and a hash table of
72 longwords.  Each longword can point to the header of another file item,
either another directory or a file.  To list out all the files in a directory,
you've essentially got to start at the first table entry and check if its
NULL.  If not, read the block it points to (file or directory), and get the
file name.  Then check the hash chain field of this entry.  If its non-NULL,
then you read the block it points to.  Once you get a NULL chain entry,
you take the next hash table link, and start over.  After 72 total entries
in the main directory block, you have information on all of the files
contained in the directory (There are simple DOS calls that do all of the
dirty work for you, you merely ask for the next entry.  But what I've
described is the work that actually happens, down at the disk level).  So
if you've go 50 files in a directory, you could possibly have to move the
disk head 50 times to get a directory.  If you use the CLI command "Dir",
this looks even slower, since the files are all alphabetically sorted, so
you don't see anything until the last entry is read.

	Where this scheme wins is in finding individual file names, like
in the case of a C compilation.  In this case, the DOS applies a hashing
function to the name you give, which hashes to 1 of the 72 possible links
in a directory.  Chances are, the link you get back points directly to
the file you want.  In very large directories, you may have a few hashing
collisions, but all in all, this is a very fast way to find the actual
file IF the name is known (I won't go and explain hashing theory, but you
should get the idea).  The other big advantage of this system is that
files can be found independently of their directories.  So if for some
reason the directory entry is wiped out on a disk, its a trivial matter
to restore all of the files it contained without losing anything.

>  - Joel Plutchak
>    uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster
>    ARPA: oyster@unix.macc.wisc.edu
>    BITNET: plutchak@wiscmacc
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave Haynie	{caip,ihnp4,allegra,seismo}!cbmvax!daveh

     "You can keep my things, they've come to take me home"
						-Peter Gabriel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~