На самом деле, я думаю, что "ls" может быть быстрее. В Java определенно есть некоторые проблемы, связанные с получением информации о файле. К сожалению, нет эквивалентного безопасного метода рекурсивного ls для Windows. (DIR / S cmd.exe может запутаться и генерировать ошибки в бесконечных циклах)
В XP при доступе к серверу в локальной сети у меня уходит 5 секунд в Windows, чтобы получить количество файлов в папке (33 000) и общий размер.
Когда я рекурсивно повторяю это на Java, это занимает у меня более 5 минут. Я начал измерять время, необходимое для выполнения file.length (), file.lastModified () и file.toURI (), и обнаружил, что 99% моего времени уходит на эти 3 вызова. 3 звонка, которые мне действительно нужно сделать ...
Разница для 1000 файлов составляет 15 мс по сравнению с 1800 мс на сервере. Сканирование пути сервера в Java смехотворно медленное. Если нативная ОС может быстро сканировать ту же папку, почему не может Java?
В качестве более полного теста я использовал WineMerge на XP, чтобы сравнить дату изменения и размер файлов на сервере с локальными файлами. Это повторялось по всему дереву каталогов из 33 000 файлов в каждой папке. Общее время 7 секунд. Java: более 5 минут.
Таким образом, исходное утверждение и вопрос из ОП верны и действительны. Это менее заметно при работе с локальной файловой системой. Локальное сравнение папки с 33 000 элементов занимает 3 секунды в WinMerge и 32 секунды локально в Java. Итак, опять же, Java в сравнении с нативным - это 10-кратное замедление в этих элементарных тестах.
Java 1.6.0_22 (последняя версия), гигабитная ЛВС и сетевые подключения, ping менее 1 мс (оба в одном коммутаторе)
Ява медленная.