On Mon, Jul 11, 2005 at 12:35:36AM -0700, Michael G Schwern wrote:
> I still can't reproduce this on OS X.
I guess the filesystem you have doesn't have the nlinks > 2 property
> On Sun, Jul 10, 2005 at 07:31:02PM +0100, Dave Mitchell wrote:
> > So we either fix the docs, as suggested, or fix the code to stat *every*
> > entry before calling the wanted function. The latter would defeat the
> > purpose of the optimisation, so I vote for the former.
>
> I'd be interested to see, given how much work File::Find does anyway,
> just how much a performance hit fixing this would be.
It makes a huge difference on my laptop (slow disk):
use File::Find;
$File::Find::dont_use_nlink = $ARGV[0];
my $count=0;
find(sub { $count++ }, '/usr');
print "count=$count\n";
running this the first time with arg0 = 0 took about 3 minutes; rerunning
it takes about 10 secs because all the directory reads are cached by the
OS.
Susequently running with arg0 = 1 (bearing in mind that the directories
are still cached) takes about 6 minutes on both the first and subsequent
runs, presumably because my laptop hasn't got enough free ram to cache
all 300K inodes that have to be read under /usr.
CPU usage is almost zero; the code is completely IO bound.
Perhaps the best approrach would be to document that an lstat is no longer
guaranteed, but add a new option to the find() options hash, 'lstat',
that if true, reinstates the guarantee.
--
Now is the discount of our winter tent
-- sign seen outside camping shop
