Multithread und File I/O bei SSD/HDD

[Sir Rufo]

@Luckie

Das ist das Grundprinzip der Pipeline, bzw. so sollte man das mit einer Pipeline aufbauen

[Luckie]

Mist. Ich wollte das Prinzip gerade zum Patent anmelden. Aber vielleicht mache ich noch runde Ecken dran und versuche es trotzdem.

[Benmik]

Zitat von Valle:

...nach jedem einzelnen Testlauf einen Rechnerneustart durchgeführt...

Hab ich! Und sogar die Festplatten dabei noch kurz stromlos gemacht, für alle Fälle.

Ich finde ja auch, dass Sir Rufo Recht hat, aber ich hatte seinerzeit sehr viel ausprobiert, um den schnellsten Weg zu einem Vorschaubild zu finden, und IExtractImage fand ich einfach am besten. Ich bin auch gar nicht so sicher, ob ein Einlesen in einem separaten Thread etwas bringen würde, denn vermutlich ist nicht das Einlesen selbst, sondern das Positionieren des Lesekopfes der entscheidende Flaschenhals. Ich habe mal die Dateien von FP1 in den FastStone Image Viewer eingelesen. Der brauchte 5 Sekunden länger als mein Programm. Merkwürdigerweise brauchte er die gleiche Zeit, wenn ich die JPG von der SSD eingelesen habe. IrfanView braucht 30 Sekunden weniger, aber ich vermute, das zeigt nur die Vorschaubilder an und speichert keine weitere Daten, so wie mein Programm und offensichtlich auch FastStone das tun. Insgesamt liege ich also offenbar nicht schlecht.

Nun kommen mir ganz verwegene Gedanken (wobei auch ein gewisser Spaßfaktor dabei ist): Wie wäre es, wenn man die Position der Dateien auf der Festplatte ermitteln (siehe mal hier und hier und hier) und sie dann entsprechend ihrer physischen Position einlesen würde? Wäre das sinnvoll? Was ist eigentlich mit Native Command Queuing?

[Valle]

Dein Betriebssystem und dein Dateisystem sollten sich gut genug darum kümmern können. Ich glaube kaum dass du hier sinnvoll optimierne kannst. Wichtig ist nur, dass du eindeutige Signale für dein Betriebssystem setzen kannst. Wenn du ein Verzeichnis an Dateien iterierst, dann können moderne Heuristiken dich schon sehr gut dabei unterstützen. Es wird dann oft schon präventiv eingelesen. Funktioniert natürlich nicht, wenn Dateien überall verteilt sind.

Mein Ansatz wäre es dann, eine Queue im RAM anzulegen und einen Thread (bis zur maximalen Befüllung) diese Queue befüllen zu lassen. (n-1) andere Threads arbeiten die Queue ab. Der einlesende Thread speichert die Ergebnisse der anderen Threads gelegentlich zurück. Wenn du blockweise arbeitest (nicht ein Bild abspeichern, sondern immer gleich 100 oder so; je nach RAM; währenddessen das Einlesen einstellen) solltest du die besten Ergebnisse haben.

[Benmik]

Ich denke auch, dass ich diesen Ansatz jetzt erstmal nicht weiter verfolgen werde. Das Plattenkraspeln bei FP2 und die deutlichen Unterschiede zwischen FP1 und FP2 lassen mich aber doch glauben, dass man das Einlesen verbessern kann.

Ich arbeite ja schon mit einem Threadpool. Wenn die Dateien erstmal im Arbeitsspeicher sind, ist, glaube ich, wenig an Geschwindigkeit herauszuholen. 23 Sekunden für ~1.200 Dateien macht rechnerisch 19 msec für das Dekodieren und Verkleinern eines JPG bei einem älteren Vierkerner. Damit kann man zufrieden sein. Dank an euch.