Re^2: 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;
}
[download]

Comment on Re^2: File::find preprocess problem Download Code

Replies are listed 'Best First'.
Re^3: File::find preprocess problem by zentara (Cardinal) on Apr 27, 2012 at 10:05 UTC
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. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]
Re^4: File::find preprocess problem by Marshall (Canon) on Apr 27, 2012 at 11:51 UTC
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]
Re^5: File::find preprocess problem by Anonymous Monk on Apr 27, 2012 at 14:16 UTC
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	[reply]
Re^5: File::find preprocess problem by zentara (Cardinal) on Apr 27, 2012 at 14:48 UTC
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. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]
Re^5: File::find preprocess problem by Anonymous Monk on Apr 28, 2012 at 03:07 UTC
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).	[reply] [d/l]
Re^6: File::find preprocess problem by Anonymous Monk on Apr 28, 2012 at 04:07 UTC