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