in reply to File::find preprocess problem

the preprocess returns everything, so obviously I'm doing something wrong.

I don't have a directory tree to test on, but I think you are using preprocess in the wrong manner by returning a set of files. Preprocess should work by returning empty, unless some condition is met. Some pseudocode: ( my logic is probably not syntactically correct, but it shows the idea) :-) 

sub preprocess{
     if( $File::Find::dir =~ m/advanced/ ){
         return $File::Find::prune = 1
          }

     return unless -f $File::Find::name;
     return unless $File::Find::name =~ m/\.log/;
}

[download]
I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Replies are listed 'Best First'.
Re^2: File::find preprocess problem
by Marshall (Canon) on Apr 26, 2012 at 21:08 UTC
    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;
}

    [download]
[reply]
[d/l]
[reply]
        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.

[reply]

In Section Seekers of Perl Wisdom