in reply to Re: opendir in file find
in thread opendir in file find

You can save a little overhead by reusing the stat buffer using the magical filehandle '_', 

"doh! can't read directory $file!\n"
  if (-d $file and not -r _);

[download]

In the case of File::Find, they guarentee that lstat will have been called before the wanted sub is called, so rather than 

sub wanted{
    print $File::Find::name if -d $_ and $r $_;
}

[download]

you can use 

sub wanted{
    print $File::Find::name if -d _ and -r _;
}

[download]
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Replies are listed 'Best First'.
Re^3: opendir in file find (anti-optimization effects)
by tye (Sage) on Jul 25, 2003 at 17:36 UTC
    You can save a little overhead by reusing the stat buffer using the magical filehandle '_',

    Yes and no. You can do that if you first disable File::Find's overeager "optimization" via: 

        $File::Find::dont_use_nlink= 1;

    [download]
    If you don't do that first, then File::Find will skip doing lstat in some cases and your use of _ will give you stale data (data for the wrong file) in those cases.

    I'd much rather you have to request this optimization when you want it (which, on some file systems, can speed up Find operations where you don't care about anything but the file name), but p5p seems pretty violently against making this "optimization" opt-in instead of opt-out.

                    - tye
[reply]
[d/l]

      Thanks for the heads-up on this. I don't make a lot of use of the module, but that is worth noting.

      Where does that sit with this statement in the 5.8 pod though?

      It is guaranteed that an lstat has been called before the user's wanted() function is called. This enables fast file checks involving _.
      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
[reply]

        The sentence directly before what you quoted is:

        If either *follow* or *follow_fast* is in effect:
        which is what makes the statement you quoted correct.

        It would be nice if the module also documented that "don't use nlink" also had this effect (and made it as easy to not use nlink as it is to specify 'follow' or 'follow_fast').

        But I won't submit such a patch after the reaction I got the last few times I've had the gal to criticize the nlink hack"optimization" to p5p. q-:

                        - tye
[reply]
Re: Re: Re: opendir in file find
by skyknight (Hermit) on Jul 25, 2003 at 17:28 UTC

    Way cool. I have never before come across said magical file handle in my travels. I shall have to remember that bit of Perl arcana, though admittedly we might be willfully trading code comprensibility for performance. Of course, in this scenario it may result in our statting each file one third as many times as we may otherwise have, so if we're blasting through a directory structure of thousands of files it will be well worth it.

[reply]

In Section Seekers of Perl Wisdom