Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!pilchuck!del
From: del@Data-IO.COM (Erik Lindberg)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Large number of files slows machine.
Message-ID: <1078@pilchuck.Data-IO.COM>
Date: 20 Dec 88 13:50:38 GMT
References: <8545@j.cc.purdue.edu> <7192@chinet.chi.il.us>
Reply-To: del@pilchuck.Data-IO.COM (Erik Lindberg)
Organization: Data I/O Corporation; Redmond, WA
Lines: 26

In article <7192@chinet.chi.il.us> ward@chinet.chi.il.us (Ward Christensen) writes:
>In article <8545@j.cc.purdue.edu> tim@j.cc.purdue.edu (Timothy Lange) writes:
>>I am dealing with an user that has around 650 files in a subdirectory.
>>We noticed that accessing the files at the bottom of the DIR listing
>>is much slower than the files near the beginning.  The performance
>>really drops off at about the 512th file.
>  That's an easy one.  I have had it happen many times.  (of course it
>wasn't easy at FIRST  ;-).
>  What is happening is the fragmentation of your directory resulting in
>many seeks while processing the directory.

This might seem to be what is happening on your system, but it isn't right.
I run a large disk cache on my system, the directories easily fit in cache
memory. I have observed the same behaviour: a massive increase in file
access time when the number of files in a subdirectory exceeds 512. And
that is with *NO* physical disk activity at all.

>  THe solution is very simple: fewer files; or more realistically for your
>application: compress the disk such as with Norton Advanced Utility's SD

Fewer files would be nice if the application would not suffer for it. I
doubt if SpeedDisk will provide significant improvements.

-- 
del (Erik Lindberg) 
uw-beaver!tikal!pilchuck!del