ins_adjb@jhunix.UUCP (09/02/87)
I have a question about searching your directory path. Is it more efficient to have many small directories in your path, or to have fewer, larger directories? --- Dan Barrett ins_adjb@jhunix.UUCP barrett@hopkins-eecs-bravo.arpa
dillon@CORY.BERKELEY.EDU.UUCP (09/03/87)
>I have a question about searching your directory path. Is it more efficient >to have many small directories in your path, or to have fewer, larger directories? >--- >Dan Barrett ins_adjb@jhunix.UUCP > barrett@hopkins-eecs-bravo.arpa It is more efficient to have fewer, larger directories when searching for a specific file. This is due to the fact that directories on the Amiga are hashed rather than organized linearly. -Matt
peter@sugar.UUCP (Peter da Silva) (09/05/87)
In article <5215@jhunix.UUCP>, ins_adjb@jhunix.UUCP (Daniel Jay Barrett) writes: > I have a question about searching your directory path. Is it more efficient > to have many small directories in your path, or to have fewer, larger > directories? Fewer, larger ones. When you know the name of a file, large directories are better. When you don't know the name, small directories are better. In your path you're looking for a known file name. A single large directory is not going to need more than a few of disk hits before it finds the file. A lot of small directories will require 1 or 2 hits in each directory. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
ba@pnet02.CTS.COM (Bill Allen) (09/08/87)
How 'bout that PATH command?
Anyone gotten around the you-are-forced-to-have-the-current-dir-
searched-first-and-c:-searched-last format?
I want the dirs I specify (and only the ones I specify) to be
searched in the order I specify.
Anyone seen a PD NewPath-like command going around?
UUCP: {hplabs!hp-sdd!crash, seismo!scgvaxd!cadovax}!gryphon!pnet02!ba
INET: ba@pnet02.CTS.COMbryce@hoser.berkeley.edu (Bryce Nesbitt) (09/09/87)
In article <1471@gryphon.CTS.COM> ba@pnet02.CTS.COM (Bill Allen) writes: >How 'bout that PATH command? >Anyone gotten around the you-are-forced-to-have-the-current-dir- >searched-first-and-c:-searched-last format? >I want the dirs I specify (and only the ones I specify) to be >searched in the order I specify. >Anyone seen a PD NewPath-like command going around? Long time ago I tried to modify the ARP (Amigad** Replacement Project) path to do this. Turns out the pathlist that a program can twiddle imposes this order. I've often wanted to set some obscure directory of infrequently used commands to happen *after* c:, which gets used all the time. You can kludge it, naturally: path vd0:common_commands ;even more common than c path c: ;here's c:, right up front path obscure_1: ; assign c: obscure_2: ;here's the kludge. Like all kludges, this almost works. The "why" function is really weird. It looks at c:fault. Yes "c:". So unless you put fault in obscure_2 you will have many headaches. Don'cha love BCPL? BTW: Don't ask me about ARP, ask Charlie Heath or see Fish disk #53, though ARP has changed much since then. ---- Commodore-Amiga finally got back at Jack Trameil (sp?)... Tim King, author of the BCPL kludge called "AmigaDOS" is reportedly writting an operating system for Atari! (Situation real, implications null, void and :-) |\ /| . Ack! (NAK, EOT, SOH) {O o} . (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/10/87)
In article <5215@jhunix.UUCP> ins_adjb@jhunix.UUCP (Daniel Jay Barrett) writes: > I have a question about searching your directory path. Is it more efficient > to have many small directories in your path, or to have fewer, larger > directories? [Bear with me if this is a repeat I'm a bit behind] Empirical evidence suggests that the two killers in directory performance are disk fragmentation and large files. Both of these are tickled by the fact that the current handler for disk files doesn't use the 'Size' field in the disk header to determine the size of the file and thus it seeks out and reads every extension block to determine the filesize. It can be argued that this is 'good' because is doesn't put any limit on file size but on floppies is a non-win since files can't span volumes anyway. To reduce fragmentation, format a disk and then use Copy All to copy all of the files over, on your data disks this can improved performance 10 - 50%. Another minor problem crops up when the number of files in the directory exceeds the optimal size given the hash table size of 76 entries. Lots of files cause hash collisions and thus extra lookups as the handler moves down the hash chain doing string compares. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.