s/optimization/"optimization"/; s/speed/a speed-up for rare uses and a slow-down for common uses of it/;
"use nlinks" should be something that is only done when requested and you should only request it if you are selecting files only based on the file name and you don't care if your code rather easily breaks in the face of all-too-common file systems that the File::Find maintainers still try to pretend don't matter much (and if the speed-up is that important to you). Using it otherwise actually makes File::Find run slower than it needs to.
Yes, I've notified p5p of these problems. But I gave up doing so many years ago. Yes, I realize that they now claim to auto detect when it would break things, but their previous (multiple) claims of safe auto detection were laughably incomplete (and I notified them of this) so I doubt (especially since we still get nodes like this) that the new detection is sufficient.
I particularly like "If you do set $File::Find::dont_use_nlink to 1, you will notice slow-downs". I notice speed-ups. But please, state it more forcefully and it will surely become true. (:
Now, the speed-up when only caring about file names (and only about suitably vanilla Unix file systems) is more significant than the speed-up I get by turning off their "optimization" for the more common uses of File::Find, so I'm not that surprised that some have formed an emotional attachment to it. But I've been burned by File::Find just plain not working so many times (I mostly stopped using it directly long ago but I still sometimes run into tools that try to use it) and I find my emotional attachment to wanting things to actually work to validly trump concerns of speed (especially since my way is faster most of the time anyway).
|