Path: utzoo!attcan!uunet!samsung!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!gl8f From: gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) Newsgroups: comp.sys.atari.st Subject: Re: Re: Full UUCP implementation for the ST? Message-ID: <1990Jul20.171108.16489@murdoch.acc.Virginia.EDU> Date: 20 Jul 90 17:11:08 GMT References: <1990Jul19.173152.1647@murdoch.acc.Virginia.EDU> Sender: news@murdoch.acc.Virginia.EDU Organization: Department of Astronomy, University of Virginia Lines: 25 In article steve@thelake.mn.org (Steve Yelvington) writes: >Even with that help, though, we found that creating new files involved >significant overhead, especially when the directories got big (sometimes >300 or 400 files) and the drive got fragmented. Unbatching large >quantities of Usenet news was taking more time than receiving it at >1200bps. This is a problem on many operating systems -- they use a poor algorithm to search in directories, so performance goes to heck, or the directory gets fragmented on disk, which means even efficient search algorithms can be slow. There was a discussion about this on comp.unix.wizards recently. The traditional work-around is grab one character from the filename and put the file in that subdirectory with that name, i.e. "fred" would be "f\fred". Then you end up with 36x fewer files on average per subdirectory and things run at a traditional speed. Of course, the best solution is to change the algorithm, and it sounds like you guys have made the right trade-offs between memory and disk to speed things up substantially. Is it faster than C News yet? ;-) -- "In fact you should not be involved in IRC." -- Phil Howard