A couple years ago I was troubleshooting a performance problem with jEdit’s file browser. Since the built-in Swing file browser lacked some advanced features, the jEdit developers had decided long ago to roll their own. Unfortunately this led to a severe performance problem that has plagued Windows users that try to access network folders containing hundreds of files. The problem had bothered me for quite a while and finally I decided to checkout the source and see if I could fix the problem. The test case I established for this effort was a network folder with 1000 small files, which in jEdit 4.2 final took 17 seconds to load in the file browser.
After much spelunking I discovered that the primary culprit is the java.io.File class, which turned out to have terrible performance characteristics when reading file attributes under Windows. Further digging revealed that every time you read a file attribute using the File class, a native call is made to the operating system to retrieve the attribute. Sounds reasonable, but as far as I know the Win32 native API only provides bulk read access to attributes and thus you must retrieve all file attributes even if you only need one. So my guess is that this bulk retrieval is expensive under Windows and that Java does not cache the attributes for subsequent reads. Therefore you incur the same bulk retrieval penalty for every attribute of a file you read.