Ich habe ein Java-Programm zum Synchronisieren meines Desktop-PCs mit meinem Notebook geschrieben. Das Programm läuft auf dem Desktop-PC, muss aber natürlich auch die über Samba erreichbare Datenpartition meines Notebooks rekursiv durchsuchen.

Ich habe auf beiden Rechnern sowohl Windows 7 als auch Ubuntu mit derselben Java-Version 7.0. Für folgenden Test habe ich sämtliche Funktionen meines Programms auskommentiert und nur noch das rekursive Durchsuchen meiner Notebook-Partition drin gelassen: Wenn der Desktop-PC mit dem Java-Programm unter Ubuntu läuft, dann ist das Programm wesentlich schneller (~1 Minute) als wenn er unter Windows 7 läuft (~8 Minuten). Welches Betriebssystem auf meinem Notebook gestartet ist (wo also auch der Samba-Server läuft) ist für die Laufzeit egal. Eine schlechte Konfiguration des Samba-Servers, was ja die naheliegendste Ursache wäre, ist damit ausgeschlossen.

Was das ganze noch eigenartiger macht: ein "dir /s \\notebook\data" (rekursives dir) in der Kommandozeile von Windows 7 ist ebenfalls schnell.

Langsam ist das Durchsuchen also nur, wenn es
1. von Java aus
und
2. von einem Windows-Rechner aus passiert.

Testhalber habe ich auch die Rollen von PC und Notebook vertauscht: selbes Ergebnis. Es liegt also anscheinend wirklich am Betriebssystem.

Hat jemand eine Erklärung für dieses Verhalten? Bzw. weiß jemand was die java.io.File-Klasse da eigenartiges treiben könnte, das die Laufzeit so massiv beeinträchtigt?

Seiten zur Beschleunigung des Netzwerks unter Windows 7 habe ich schon einige gelesen. Davon hat nichts geholfen. Das Netzwerk an sich ist ja auch nicht das Problem, weil das Listen direkt von der Kommandozeile aus ja effizient ist (inzwischen habe ich es auch in C# implementiert und es ist ebenfalls effizient). Es liegt also unmittelbar an der Windows-Implementierung vom JDK. :mad:

Ich könnte mir vorstellen dass das JDK auf generische Betriebssystemfunktionen zum Dateizugriff zurückgreift, während die Shell und .NET erkennen dass es Samba ist und spezifische System Calls machen. Macht das Sinn?

Kennt jemand eine andere Implementierungsmöglichkeit zum rekursiven Traversal an Stelle von File.isDirectory() und File.list()?

Um es für die Nachwelt festzuhalten: mit dem java.nio-Package geht es etwas schneller als mit java.io.File. Beschrieben wird das z.B. hier: http://stackoverflow.com/questions/1052…ively-in-java-7.

Der Geschwindigkeitsvorteil ist unter allen Betriebssystemen spürbar, jedoch ist Windows+schnelles java.nio immer noch langsamer als Linux+langsames java.io. Anscheinend ist der Dateizugriff im Windows-JDK einfach ineffizient implementiert, aber da kann man halt nichts machen. Ist für mich auch nicht so tragisch.