20.000 File filtern

[SaschaLR]

Hallo!

Ich habe ein Performance-Problem.

Ich muss aus 4 Verzeichnissen ca. 20.000 Files filtern. Das ganze in 2 Stufen, zuerst nach Datum und dann nach dem Namen. Filtern heisst in dem Zusammenhang, dass nur Files die ein bestimmtes Datum haben und deren Name bestimmte Kriterien erfüllt, in eine ArrayList übernommen werden.

Ich bin grade beim Datumsfilter, der in Form einer JComboBox vorliegen wird und ein Datum nur dann enhält, wenn mind. eine Datei mit diesem Datum gefunden wurde.

Mein Problem ist, dass es ziemlich lange Dauert die 20.000 File zu durchforsten. Ich hoffe jemnd kann mir einen Tip geben, wie es schnel lwerden könnte.

public static HashSet<String> loadData(ArrayList<File> folders) {
	HashSet<String> temp = new HashSet<String>();
	String date = null;
	for (File folder : folders) {
		for (File file : folder.listFiles()) {
			date = sdf.format(file.lastModified());
			temp.add(date);
		}
	}
	return temp;
}

Kurze Erklärung:
- sdf ist ein SimpleDateFormatter("yyyyMMdd")
- folders enthält die 4 Verzeichnisse
- temp soll am Ende jedes Datum einmal enthalten.

Ich hatte überlegt, ob ich nicht auf diese Idee ganz verzichte und einfach jedes Datum als Filter zulasse und ggf. eine leere Liste anzeige wenn es keine Dateien zu dem Datum gibt. Leider ergab das auch keine bessere Performance, weil ich dann in meinem FileFilter jede Datei einmal anfassen und im Prinzip die selben Operationen wie oben damit ausführen musste.

Hat jemand eine Idee? Gibt es schon eine Lösung in der Java-API auf die ich nur nicht gekommen bin? Sowas wie einen fertigen Datums-Filter für Dateien oder so?

Dank und Gruß,
Sascha

 

[Mario_H]

Was, wenn du die Dateien nach Datum sortiert einmal einliest (dauert auch lange, einmal) und danach diese sortierte Liste verwendest, müsste dann nach dem ersten einlesen deutlich schneller gehen.

 

[Kola]

Du filterst ja nach 2 Kriterien. Dann sollte man immer (bei Kenntnis der Anwendungsdomäne) die Filterung, die die Resultatmenge am meisten einschränkt, zuerst ausführen.

Allerdings würde ich mir üblerlegen, ob ich nicht schnell einen Systembefehl ("ls" oder "dir") ausführe, der die ganze Filterung erledigt.

 

[SebiB90]

übergib doch listFiles() nen FileFilter, dann bekommste nur die dateien die du auch willst und musst nicht nachträglich nochmal filtern

 

[SaschaLR]

@SebiB90 hab ich ja shcon versucht, siehe Posting

@Mario_H genau das tue ich bereits

@Kola so einfach ist das leider nicht, da zur Laufzeit die beiden Filterkriterien ständig geändert werden. Für ein bestimmtest Datum kann der 2. Filter schnel langepasst werden. Das ist dann auch kein Problem mehr. Aber die Idee mit dem 'ls' ... bzw 'dir' ist garnicht schlecht... mal sehen...

Das Problem ist wirklich, dass ich einmal alle 20.000 Dateien anfassen muss. Wäre eben schön, wenn es schon eine API-Funktion gäbe die irgendwie mit dem FS zusammenarbeitet und sich zB nur Dateien vom xx.yy.zzzz geben lässt ... ohne Java-FileFilter ...

 

[Mario_H]

Wenn du die Dateien schon nach Datum sortiert in einer Liste hast stimmt das aber nicht:

Ich hatte überlegt, ob ich nicht auf diese Idee ganz verzichte und einfach jedes Datum als Filter zulasse und ggf. eine leere Liste anzeige wenn es keine Dateien zu dem Datum gibt. Leider ergab das auch keine bessere Performance, weil ich dann in meinem FileFilter jede Datei einmal anfassen und im Prinzip die selben Operationen wie oben damit ausführen musste.

[/b]

 

[SaschaLR]

Ja, aber das sortierte Einlesen erspart mir das lange lange Warten nicht. Darauf wollte ich eigentlich hinaus.

Sicher, wenn ich einmal nachdem Datum sortiert habe geht alles was danach kommt schön fix, aber das einmalige Einlesen und sortieren dauert dennoch ewig. ... genauso habe ich es ja von Anfang an gemacht...

Was mir eben viel ersparen würde wäre sozusagen ein Aufruf der eben nur die Dateien vom xx.yy.zzzz zurückgibt. Ohne dass ich in meinem Code einen FileFilter mit der Funktion laufen lassen muss.

 

[Mario_H]

Was meinst du mit lange? Ich tipp auf ca. eine Minute, eher weniger... ?

Das muss beim Programmstart ja nur einmal geschehen...

Warum sollte besagter Aufruf so viel schneller arbeiten als dein FileFIlter?


Vielleicht dauert das einlesen so lange, weil du eine ungeeignete Datenstruktur verwendest bzw. die Startgröße schlecht gesetzt ist..

 

[Mario_H]

p.s. mach mal suchen *.* [geändert am ...] in deinen Ordnern mit dem Windows-Explorer. So lang dauert es mindestens, so oder so.

 

[SaschaLR]

Mit lange meine ich >30 Sekunden ... allerdings kann die Liste auf Knopfdruck aktualisiert werden ... d.h. je Klick auf "Aktualisieren" > 30 Sekunden ...

Und wer bitte benutzt denn den Explorer? Sowas hab ich garnicht Bei mir im Finder geht's in Windeseile ... aber das nur als Scherz am Rande

 

[Gast]

Hi,
egal was du machst, einmal musst du mindestens über alle Dateien rüber. Das dauert natürlich schon mal ein wenig. Die Sache ist, dass dein Momentaner Weg nicht sehr schön ist. Du verwendest eine Struktur, die nicht nötig ist : Strings. Nicht dass Strings nicht schön sind, aber schnell ist doch eher etwas anderes. Dein Datum wird als Long geliefert. Dein Hauptproblem ist also, dass du hier long Werte hast, die dir zu genau sind (du möchtest nur auf den Tag genau).
Eine Möglichkeit wäre es, statt umständlich einen String zu erstellen das Datum als Date zu parsen (also ein HashSet<java.util.Date> zu verwenden).
Das ist zwar noch nicht die optimale Lösung, aber das unnötige Erzeugen eines Strings fällt weg. Letztlich wird etwas ähnliches sihcherlich auch gemacht bevor der String fertig ist.
Zudem sollte der Vergleich zwischen zwei Daten auch noch schneller sein als der eines String. Ein long dürften ja so ca. 64 Bit + 1 VZ Bit sein. Bei einem String der Form yyyymmdd hast du schon die doppelte Menge für den Inhalt + den Overhead des Strings (natürlich hat auch ein Date Overhead!)
Das ganze als long wäre noch interessant. Der letzte Zugriff ist ja so weit ich mich da nicht irre nur die Anzahl der Millisekunden seit einem festen Datum. Hier kannst du ja leicht ausrechnen, wie du nur auf ganzzahlige Tage kommst. Dann musst du nur noch longs speichern, dass dürfte noch ein wenig bringen.
Ganz schlecht ist es wohl auch, dass du ein Hashset verwendest ohne hier die Initialgröße zu verändern. Ein Hashset muss natürlich bei jeder Größenänderung ein Rehashing durchführen. Das kostet natürlich Zeit. Gibst du keine Startgröße an, dann wird ein Set mit 16 Elementen angelegt und bei 75% Füllung wird dies vergrößert. Da bin ich mir jetzt nicht sicher, wieviel größer es wird, aber wahrscheinlich kommen einfach 16 Elemente hinzu...
Initialiesiere es einfach mit einer Größe, die für dich wahrscheinlicher ist. Keine Ahnung wieviele verschiedene Daten du hast, aber musst du halt abschätzen (und im Konstruktor übergeben). Wird weniger Rehashing nötig, dürfte das ein wenig Zeit ausmachen. Du solltest natürlich auch daran denken, dass ein unheimlich großer Wert auch unheimlich viel Speicher braucht, also schon einen sinnvollen Erwartungswert nehmen!

Ja, versuch es mal mit den Änderungen, vielleicht merkst du ja schon einen Unterschied!

 

[Gast]

Ahso, du kannst natürlich die Differenz zu einem festen Datum (z.B. wie das von java.util.Date) auch direkt in Tagen in das HashSet packen.
Dann würdest du schon mit int auf über 5 Mio Jahre kommen (was aber nur noch 32 Bit sind und damit weniger Speicher + Registerbreite!)