ListFiles performance vs file system visitor

[Alan Bateman]

Paulo Levi wrote:
> :
> I mean that the current File class has a private constructor
> File(String child, File parent) that doesn't do file normalization.
>
> If isDirectory() doesn't require filename normalization i would have
> the opportunity to normalize lazily the first time the files were
> used, since File is not final.
>
> But  if the problem is not listFiles() it is obviously isdirectory().
>
> If i call listFiles on a normal file it should return null right? I
> wonder if that is faster than the isDirectory call itself... no reason
> to but doesn't hurt to check.
>
> Also isDirectory() performance fixes? Make File(String child, File
> parent) protected?
>
> Pleeeeease?
>
> Also i just noticed. Disregard the sort there, the times i told where
> before i added that.
>   
Sorry, I don't understand what you proposing here. The File class was 
never designed to be extended and should have been a final class.

I did a quick test with a FAT32 drive (5400rpm, <13ms seek) connected to 
a Windows XP machine via USB (2.0, not 1.1 as I couldn't find anything 
that old). The drive has 28,000 files spread over 1850 directories and 
the test simply searches the entire disk for ".java" files.

Using Files.walkFileTree my build takes ~11.9s for the cold-start case 
(drive just connected, nothing in the file cache) and 320-340ms for 
second and subsequent runs.

Using listFiles + isDirectory (like the code fragment you posted) it 
takes 15.0-15.4s for the cold-start case and 2890-2920ms for second and 
subsequent runs.

Using only listFiles (ie: assume every file is a directory and check for 
null as you suggest) then the test takes 15.0-15.4s for the cold-start 
case (same as previous) and 2845-2860ms for second and subsequent runs 
(marginally better than previous).

Your initial mail was comparing the performance against Windows search. 
I'm assuming this is the Search tool that be started from the Start menu 
- is that right? If so, then I tried it and the wall-clock time was 
26-28s for the cold start case. This is very different to the 6s you 
mentioned so perhaps you might be doing something else or pilot error on 
my part.

-Alan.