AW: Lightroom 3 released!
Ich habe mal den guten Tipp mit Procmon genutzt und mein LR analysiert.
Ergebnis:

Auf D: liegen die RAWs, Cache in M:AITEMP. Der Rest ist wohl klar. D: ist eine einzelne Platte und M: ein Raid-0 aus 2 Platten des gleichen Typs wie D:.
Seagate 7200.11 750er
C: liegt auf einer 4ten Platte.
OS: Win7 64Bit, i7-860, 8GB
Ich bin in einem Folder mit 876 Bildern (JPG und RAW einzeln, also eigentlich 438 Bilder, alle 5DII) die 126 von mir als ordentlich geflagten druchgegangen und habe jeweils die Umstellung auf den neuen LR3 Entwicklungsprozess ausprobiert.
Das sollte doch sehr ähnlich einem Entwicklungsdurchgang sein bei dem nicht so viel an den Regler gedreht wird, aber die 1:1 previews auch neu berechnet werden.
Die meiste Zeit geht mit 100 Sekunden im Cache drauf. Die RAW werden auch angefasst, allerdings (im Bild nicht sichtbar) liegen die Zeiten für das Laden eines RAW bei <0,15 s.
Die meiste Zeit wird im Cache-Verzeichnis verbracht (bei mir übrigens auf 40 GB eingestellt) danach die Previews und dann erst die RAWs und wie gesagt, sollte M: doppelt so schnell sein wie D:. Es werden hier auch recht große Brocken an Daten gelesen, das wird schon hinkommen.
Also sollte man wohl am besten den Cache auf eine möglichst schnelle Platte legen und wohl auch möglichst groß machen und den Katalog und die Previews auch gleich noch dazu.
Die RAWs kann man auf anscheinend gut auf einer normalen Platte haben.
Wieviel schneller wird es?
Ich schätze LR hat so 3,5 Sekunden an jeden Bild herumgeschraubt (Laden, Prozess umstellen, ggf. wieder Undo, alles bei 1:1).
126 * 3,5 s = 441s ... wären also bei meinem System ca. 173s/441s ~ 40% der Zeit für Fileoperationen drauf gegangen.
Speicherverbrauch von LR ging dabei nicht über 2 GB.
EDIT:
Wie sich später bei Tests mit SSDs usw. ergab, bekommt man die Zeit für Dateioperationen zwar deutlich runter. Das ändert allerdings nichts an der Bearbeitungszeit. Lr ist offensichtlich so gut im Parallelisieren, dass die IO-Zeiten einfach keine Auswirkung haben, da die CPU sowieso so lange braucht für die Berechnungen.
Ich habe mal den guten Tipp mit Procmon genutzt und mein LR analysiert.
Ergebnis:

Auf D: liegen die RAWs, Cache in M:AITEMP. Der Rest ist wohl klar. D: ist eine einzelne Platte und M: ein Raid-0 aus 2 Platten des gleichen Typs wie D:.
Seagate 7200.11 750er
C: liegt auf einer 4ten Platte.
OS: Win7 64Bit, i7-860, 8GB
Ich bin in einem Folder mit 876 Bildern (JPG und RAW einzeln, also eigentlich 438 Bilder, alle 5DII) die 126 von mir als ordentlich geflagten druchgegangen und habe jeweils die Umstellung auf den neuen LR3 Entwicklungsprozess ausprobiert.
Das sollte doch sehr ähnlich einem Entwicklungsdurchgang sein bei dem nicht so viel an den Regler gedreht wird, aber die 1:1 previews auch neu berechnet werden.
Die meiste Zeit geht mit 100 Sekunden im Cache drauf. Die RAW werden auch angefasst, allerdings (im Bild nicht sichtbar) liegen die Zeiten für das Laden eines RAW bei <0,15 s.
Die meiste Zeit wird im Cache-Verzeichnis verbracht (bei mir übrigens auf 40 GB eingestellt) danach die Previews und dann erst die RAWs und wie gesagt, sollte M: doppelt so schnell sein wie D:. Es werden hier auch recht große Brocken an Daten gelesen, das wird schon hinkommen.
Also sollte man wohl am besten den Cache auf eine möglichst schnelle Platte legen und wohl auch möglichst groß machen und den Katalog und die Previews auch gleich noch dazu.
Die RAWs kann man auf anscheinend gut auf einer normalen Platte haben.
Wieviel schneller wird es?
Ich schätze LR hat so 3,5 Sekunden an jeden Bild herumgeschraubt (Laden, Prozess umstellen, ggf. wieder Undo, alles bei 1:1).
126 * 3,5 s = 441s ... wären also bei meinem System ca. 173s/441s ~ 40% der Zeit für Fileoperationen drauf gegangen.
Speicherverbrauch von LR ging dabei nicht über 2 GB.
EDIT:
Wie sich später bei Tests mit SSDs usw. ergab, bekommt man die Zeit für Dateioperationen zwar deutlich runter. Das ändert allerdings nichts an der Bearbeitungszeit. Lr ist offensichtlich so gut im Parallelisieren, dass die IO-Zeiten einfach keine Auswirkung haben, da die CPU sowieso so lange braucht für die Berechnungen.
Zuletzt bearbeitet: