Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!seismo!uunet!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!msuinfo!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.sys.mac.programmer Subject: Re: The Beauty of HFS Message-ID: Date: 31 Jan 91 17:02:41 GMT References: <1CE00001.2uro9z@tbomb.ice.com> Sender: news@msuinfo.cl.msu.edu Organization: UW-Madison CS department Lines: 19 In-Reply-To: time@tbomb.ice.com's message of 30 Jan 91 23:26:19 GMT In article <1CE00001.2uro9z@tbomb.ice.com> time@tbomb.ice.com (Tim Endres) writes: >Performance may be better, I have no data on that, but I do know that >the Mac HFS starts to really choke when a directory begins to contain >hundreds of files. Are you sure? The *Finder* slows down quite a bit. HFS itself doesn't, at least as far as I've seen, and I've played around with directories with several thousand files before (purely to experiment with its limits, if any). The HFS directory is stored as a B-tree; the key is a directory ID and the file name. Having one large directory with 700 files, say, has nearly exactly the same hit on performance as having 600 files scattered amongst 100 directories. I don't think the Finder was designed to handle large numbers of files in one directory, though. Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+