Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon From: dillon@CORY.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga Subject: Re: statement Message-ID: <8612160732.AA06465@cory.Berkeley.EDU> Date: Tue, 16-Dec-86 02:32:48 EST Article-I.D.: cory.8612160732.AA06465 Posted: Tue Dec 16 02:32:48 1986 Date-Received: Wed, 17-Dec-86 04:54:25 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: University of California at Berkeley Lines: 53 >> The icons could be speeded up by putting them all in one file in each >> directory...or in a great big file in the root directory. Then you >> could write utilities to install, copy and delete icons. A file that >> didn't explicitly have an icon definition in the "icon file" would be >> given a default "vanilla" icon, sort of what the Mac does for files it >> has no specific definitions for. > >Sorry to disappoint you, however, this would only work if it was the >*first* file you wrote to the disk and you never changed it. Since >AmigaDOS uses a hashing scheme to locate directory entries it has >no compunction about putting directory blocks close together. Thus >your "one file" may have pieces of itself all over the disk. A somewhat >better approach might be to have an "icon pointer" in directory blocks >that points to a linked list of icon file headers in that directory. >This would at least prevent you from having to scan the entire directory >for .icon files. (There are even free longwords in the Directory block >and the FileHead block structures, how about it Andy 1.3?) Sorry to disappoint you, but the one-file scheme would be extremely effective especially when compared to the 'search the entire directory and read all the info files' scheme. For one, both schemes read exactly the same information (thus your argument falls to the four winds). The whole point is to get rid of the idiotic directory searching. and your comment on about the hashing function doesn't apply at all... it doesn't really matter if it's the first file or not, just as long it is a known file. The new scheme would use a known file name and thus a known hash and for all practical purposes a single seek to get to the base block for the entire folder. Compare this to having to open each X.info file in the current scheme... one for each ICON. >> As it is, the current Workbench has enough holes in it that I would >> label it as unsuitable for the novice user. >> Mike Portuesi > >I wouldn't label it unsuitable, it has improved alot in 1.2 and I assume >it will do so even more in 1.3. I hacked together an interface for the >Lattice 3.1 C compiler that ran under workbench and it seemed to work >out fairly well. Now that some of the tools like Egad! are coming together >you should probably be on the lookout for better workbench applications. I would label it completely unsuitable... and for one reason only: It's too slow. You've talked a lot about it being 'better under 1.2'. Well, I've been using 1.2's specific workbench improvments for the past couple of months (it was in beta 4 ,all later betas, and probably some earlier versions as well), and frankly, the speed up is only somewhat noticeble. You don't seem to understand that placing everything in a single file per folder would be at least an order of magnitude faster (read 10x), if not more. -Matt