Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP Newsgroups: comp.sys.atari.st Subject: Re: Re: BYTE's review of the 1040ST Message-ID: <1418@cbmvax.cbmvax.cbm.UUCP> Date: Mon, 16-Feb-87 15:16:35 EST Article-I.D.: cbmvax.1418 Posted: Mon Feb 16 15:16:35 1987 Date-Received: Tue, 17-Feb-87 06:34:01 EST References: <1063@uwmacc.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 60 > >> 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~