"Effizienteste" Kopierroutine für eine große Datei

[pvmichael]

Hallo,

hat zufällig jemand in seinem "Nähkästchen" eine effiziente und sichere Routine um einzelne sehr große Dateien (~2000MB) zu kopieren?

Im Moment verwende ich eine Windows API Routine, die ist grundsätzlich in Ordnung, aber wenn es noch schneller geht, wäre das natürlich grandios

Würde mich freuen, wenn da jemand einen Tipp für mich hat.

Viele Grüsse

Michael

[AND51]

Solange noch niemand etwas postet, könntest du doch vielleicht deine Prozedur mal hier niederschreiben; dann haben wir anderen wenigstens auch was davon. Ich wäre durchaus interessiert an deiner Lösung.

Und sry, dass ich nicht helfen kann.

[Tafkadasom2k5]

Heyho!

Generell würde ich dir das Lesen in 4096KB-Blöcken empfehlen, damit erreicht man meistens die größte Geschwindigkeit.
Ich habe etzt nicht genau im Kopf, wie groß die maximalen Strings in PureBasic sind, aber wenn du immer in 4096er Schritten ließt, und den Rest (wie zum Beispiel bei einer 5MB-Date ^^) dann halt mit normalen Schritten, hast du meistens die beste Effizienz.

Das war damals schon bei DOS-Programmen so (bei größeren Datenmengen konnte man da bis zu 45 Minuten Verbesserung rausholen!) und müsste eigentlich bis heute so sein.
Wenn das jemand besser weiß, so soll er mich eines Besseren belehren

Gr33tz
Tafkadasom2k5

[DarkDragon]

Heyho!

Generell würde ich dir das Lesen in 4096KB-Blöcken empfehlen, damit erreicht man meistens die größte Geschwindigkeit.
Ich habe etzt nicht genau im Kopf, wie groß die maximalen Strings in PureBasic sind, aber wenn du immer in 4096er Schritten ließt, und den Rest (wie zum Beispiel bei einer 5MB-Date ^^) dann halt mit normalen Schritten, hast du meistens die beste Effizienz.

Strings haben damit doch wohl überhaupt nichts am Hut, wenn man Binäre Dateien kopiert.

[Kaeru Gaman]

> Das war damals schon bei DOS-Programmen so und müsste eigentlich bis heute so sein.

das is ja mal ganz schwach ins blaue geraten...

was soll denn FAT16 auf 16bit-DOS mit NTFS auf 32bitWIN gemeinsam haben?



> bei größeren Datenmengen konnte man da bis zu 45 Minuten Verbesserung rausholen

wahrscheinlich hat der kopiervorgang ohnehin schon 1.5h gedauert?
und "größere Datenmengen" waren 80MB?

[pvmichael]

Solange noch niemand etwas postet, könntest du doch vielleicht deine Prozedur mal hier niederschreiben; dann haben wir anderen wenigstens auch was davon. Ich wäre durchaus interessiert an deiner Lösung.

Und sry, dass ich nicht helfen kann.

Kein Problem, der Code ist allerdings nicht von mir, den hab ich aus dem Forum:

Code: Alles auswählen

Procedure CopyFileWithProgress(Parent.l,In$,Out$,Trenner$) 
;Trennzeichen in In$ durch Nullbyte ersetzen 
Trenner.b = Asc(Trenner$) 
Length.l = Len(In$) 
For Pos.l = 0 To Length - 1 
  ASCII.b = PeekB(@In$ + Pos) 
  If ASCII <> Trenner 
  PokeB(@In$ + Pos, ASCII) 
  Else 
  PokeB(@In$ + Pos, 0) 
  EndIf 
Next 
;Trennzeichen in Out$ durch Nullbyte ersetzen 
Length.l = Len(Out$) 
For Pos.l = 0 To Length - 1 
  ASCII.b = PeekB(@Out$ + Pos) 
  If ASCII <> Trenner 
  PokeB(@Out$ + Pos, ASCII) 
  Else 
  PokeB(@Out$ + Pos, 0) 
  EndIf 
Next 
SHFO.SHFILEOPSTRUCT 
SHFO\hwnd   = Parent 
SHFO\wFunc  = #FO_COPY 
SHFO\pFrom  = @In$ 
SHFO\pTo    = @Out$ 
SHFO\fFlags = #FOF_MULTIDESTFILES 
If SHFileOperation_(SHFO) = 0 
ProcedureReturn 1 
Else 
ProcedureReturn 0 
EndIf 
EndProcedure

Aufgerufen wird es dann mit:

Code: Alles auswählen

CopyFileWithProgress(#Window_0, Quelle.s+"||", Ziel.s+"||","|")

[Michael Vogel]

Hab mich mal damit herumgespielt...
http://sudokuprogram.googlepages.com/copyme.exe

Die entsprechenden Sourcen findest Du auf http://www.purebasic.fr/english/viewtop ... copyme+exe (siehe Procedure MyCopyFile)

Michael

[Thorium]

> Das war damals schon bei DOS-Programmen so und müsste eigentlich bis heute so sein.

das is ja mal ganz schwach ins blaue geraten...

was soll denn FAT16 auf 16bit-DOS mit NTFS auf 32bitWIN gemeinsam haben?

Ne ganze Menge. Der Unterschied zwischen FAT16 und FAT32 ist lediglich, das die Anzahl der Cluster als 32 Bit Wert bei FAT32 und 16 Bit Wert bei FAT16 niedergeschrieben wird. Das hat überhauptnix mit der unterstützten Registerbreite durchs Betriebssystem zu tun. Man kann theoretisch auch von 16 Bit DOS auf FAT32 zugreifen.

Ich nehme mal schwer an, das die Optimierung durch 4096 Byte Blöcke mit der Clustergröße zusammenhängt und die ist bei FAT32, wenn ich mich jetzt nicht irre eben auch 4 KB.

[Kaeru Gaman]

@thorium

ich schrieb NTFS nicht FAT32

tafka schrieb 4096KB, nicht Byte

[Thorium]

@thorium

ich schrieb NTFS nicht FAT32

tafka schrieb 4096KB, nicht Byte

Hab grad nochmal nachgeschaut, bei NTFS liegt die Clustergröße am 2 GB Partitionsgröße auch bei 4 KB.

Und mit den 4096KB nehm ich einfach mal an, dass er sich da verschrieben hat. Ich kann mir nicht vorstellen, das es zu DOS-Zeiten sinnvoll wahr 4 MB Blöcke zu kopieren. Damals hatten die Rechner ja gerade mal zwischen 4 und 16 MB RAM.