Re^2: File::find preprocess problem

[Marshall]

in reply to Re: File::find preprocess problem
in thread File::find preprocess problem

Preprocess should work by returning empty, unless some condition is met. This is not right.

I've played a bit with this option before. When File::Find enters a new directory, it does a readdir(). The output of that readdir() is what goes into the preprocess routine. What you return is a) filtered version of that or perhaps even b) a sorted version of that. If you take a directory name out of this list, find() will not follow down that path (useful for pruning off a directory branch).

I'm not sure that using the preprocess option will make any significant difference in performance in this case. Depends upon how many files are in the /advanced/ directories.

As a trick, there is a special variable _, (note not $_). When a file test is done, this causes a stat(), in this case using the _ will cause the file test info from the -f test to be re-used. This will make a performance difference - stat() is not a quick operation. There are some "yeah but's concerning various types of links - I forget the details right now, but usually this is not an issue.

Didn't test this, but I think this will work...if I got my unless logic right.

Update: Ooops, looked again it appears the the below should be changed, OP wants to process .log files and follow all directories that aren't "advanced".

sub preprocess {

   my @to_return;
   foreach (@_)
   {
      #don't follow down advanced directory paths
      #Do call wanted() on .log files (and any directory not
      #underneath an "advanced" one
       push @to_return, $_ 
          if  ( ( -f   and  /\.log$/ ) or
                !( -d _ and /advanced/) );
    }
    return @to_return;
} 

[zentara]

Thanks for clarifying that, I always used it, and seen it used as pruning type of callback; but it is quite confusing, as seen by the widespread recommendation of the File::Find::Rule and Path::Class::Rule modules mentioned above.

[Marshall]

I don't understand why so many folks like these other modules when a simple find() will often do the job!
I guess the documentation could be improved?

File::Find is a core module and it runs really fast. My hint about this special underscore variable -> that can make a big difference. It took me awhile to learn that "trick", but I very sure that this is true. That is basically about a 2x performance increase if you are doing 2 file tests.

The overhead to call a subroutine with no args (which is what find() does), is pretty much nothing compared with a file system operation.

I'm not sure that running \$preprocess even helps in OP's application. Weirdly enough, it may actually be slower due to the processing before calling \$wanted(). But this depends upon how many files/directories are underneath the /advanced/ path's and whether pruning these descent path's out from the directory descent really helps. Also how significant are the number of simple files that are not log files? Maybe these are huge in number to the .log files, maybe not.

From my experience, the single thing that will drive the performance, is the number of stat(), file system operations.

[Anonymous Monk]

I don't understand why so many folks like these other modules when a simple find() will often do the job! I guess the documentation could be improved?

Sure you do : It is tons easier, requires less brain power to use, has a more memorable interface

When is the last time you saw a question about how to use File::Find::Rule or Path::Class::Rule?

?node_id=3989;HIT=File%3A%3AFind%3A%3ARule;re=N

Found 11 nodes roughly between 2012-04-27 and 1999-10-04 (searched 100.00% of DB).

where title contains "File::Find::Rule"

<Reveal this spoiler or all in this thread>

?node_id=3989;HIT=File%3A%3AFind%20;HIS=%3B;re=N

Found 50 nodes roughly between 2012-04-27 and 2005-08-24 (searched 49.73% of DB).

Found 50 nodes roughly between 2005-08-24 and 2001-09-24 (searched 38.44% of DB).

Found 20 nodes roughly between 2001-09-24 and 1999-10-04 (searched 11.82% of DB).

Gee, 11 versus 120, and that is just on perlmonks

[zentara]

I don't understand why ..... a simple find() will often do the job...File::Find is a core module and it runs really fast

Just look at the discussion in this node, and you have your answer. :-) It needs a cookbook of runnable examples.

[Anonymous Monk]

I have to say I have not done any preprocessing before calling &File::Find::wanted yet. All the sorting happens in there. And, I certainly do not feel compeled enough to run any benchmark (but I can be convinced if other do).