Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Telling Workbench about new icons
Message-ID: <34778@sun.uucp>
Date: Tue, 24-Nov-87 16:30:21 EST
Article-I.D.: sun.34778
Posted: Tue Nov 24 16:30:21 1987
Date-Received: Sat, 28-Nov-87 06:09:57 EST
References: <1076@sugar.UUCP> <2826@cbmvax.UUCP> <1103@sugar.UUCP> <25883UH2@PSUVM>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 23

In article <25883UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes:
>About faster .icons.
>     
>Shouldn't it be pretty easy to write a *directory sorter* that moves
>all the .icon files to the front of the list so that they'd be
>the first files found and displayed?  (Who me?  It'd take me 6 months
>just to decide which C compiler to buy.)

No, because the directorys are not 'sortable'. The directory entries 
are kept in a hash table for fast initial access. Finding a named
file on the Amiga is a very fast operation, finding *all* files is
slow because these tables have to be traversed. The only enhancement
that I can think of that would be really possible would be to insure
that the .icon fileheader was pointed to by the hash entry in the 
directory blocks hash table. When more than one file name hashes to
the same value it stores them 'horizontally' in the hash table via
a linked list. Making sure .icon was at the head of this list would
insure a minimum number of reads to find it.


--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.