Delphi vs. Windows, warum kopiert Windows schneller?

[Angel4585]

Hallo!

Ich hab keine Ahnung ob ich in der Sparte hier richtig bin, aber im Verschieben seid ihr ja Weltmeister :)

Ich kopiere eine Datei mit den Methoden BlockRead und BlockWrite.

Eine 50 MB-Datei über Netzwerk braucht per Explorer(STRG+C & STRG+V) ca. 10 Sekunden.
Die gleiche Datei über Netzwerk per BlockRead&BlockWrite braucht ebenfalls 10 Sekunden.
Soweit so gut.

Nun habe ich aber eine MicroSDHC-Karte.
Die 50MB Datei per Explorer dauert ebenfalls ca. 10 Sekunden.
Die 50MB Datei per BlockRead&BlockWrite dauert hier auf einmal knapp ne Minute(57 Sekunden) :shock:

Kann mir jemand erklären wie hier dieser Unterschied zustande kommt? :gruebel:
Und kommt mir jetz nich mit Cache :mrgreen:

[Luckie]

Welche Blockgröße liest denn BlockRead/BlockWrite?

[himitsu]

Das ist die Cache (WFC) :mrgreen:

Wie kopierst du es denn genau?

[Angel4585]

Also ich darf hier nur ausschnitte posten, deshalb mal das relevante:

Delphi-Quellcode:

var 
Buf: array[1..8191] of Char;
gel, ges: Integer;
begin
repeat
try
try
BlockRead(fFrom,Buf,SizeOf(buf),gel);
BlockWrite(fTo,buf,gel,ges);
inc(iPos,gel);
except
  //IOError abfangen
  end;
until(gel<>ges)or(gel=0);
end;

Allerdings irritiert mich da selbst gerade warum das buf-Array von 1-8191 geht. Ein Block sollte doch ne Zweierpotenz sein oder? :gruebel:

[himitsu]

vermutlich ist 0..8191 gemeint

Char macht sich auch gut (dieses ist ab Delphi 2009 aber doppelt so groß)


PS: eigentlich sollte es schneller gehn, immerhin schreibst du ja in den schnellen WFC und nicht direkt auf die Karte.
Wobei ich hier auch eher in bis zu 64 KB-Schritten arbeiten würde.

Muß denn ein Fortschritt angezeigt werden?

[Angel4585]

Ja wird ein Fortschritt angezeigt, aber ich hatte testweise schon alles auskommentiert, sodass nurnoch das reine kopieren drin war. Also am Fortschritt liegts nicht.

[Namenloser]

Zitat:

Zitat von himitsu

Char macht sich auch gut (dieses ist ab Delphi 2009 aber doppelt so groß)

Unter C vielleicht, unter Delphi ist es semantisch falsch. Char ist immer ein Glied einer Zeichenkette - und nur mehr oder weniger zufällig unter Delphi<2009 genau ein Byte groß. Der Datentyp "Byte" wäre hier gefragt.

Mal abgesehen davon, was spricht dagegen, einfach direkt die Windows API-Funktionen zu benutzen? (CopyFile)
Die Windowsentwickler werden sich schon einige Gedanken darüber gemacht haben, wie sie ihre Funktionen auf Performance optimieren.

[tkone]

windows haut anfangs alles was reinpasst in den cache.
dadurch gehts anscheinend schneller

[Angel4585]

Ich hatte es heut mittag nochmal mit nem größeren Buffer getestet und tatsächlich, nimm ich anstatt 8K 64K gehts sehr schnell, innerhalb von 10 Sekunden waren die 50 MB aufm Stick.. bzw auf der Karte.

[sx2008]

Zitat:

Zitat von himitsu

vermutlich ist 0..8191 gemeint

Das könnte die entscheidende Bremse sein.
Wenn man immer ein Byte zuwenig kopiert ist das sicher schlecht für die Performance.
Ab einer bestimmten Puffergrösse (8kB, 16kB oder 32kB) bringt ein grösserer Puffer keine Verbesserung.
64kB oder 128kB bringen nach meiner Erfahrung nicht mehr als 32kB.

[himitsu]

Zitat:

Zitat von sx2008

Ab einer bestimmten Puffergrösse (8kB, 16kB oder 32kB) bringt ein grösserer Puffer keine Verbesserung.
64kB oder 128kB bringen nach meiner Erfahrung nicht mehr als 32kB.

jupp

bei mir liegen die nach eigenen Erfahrungen/Testmessungen auch so in diesem Bereich.
unter 4 bzw. 8 KB bremst es nur
und über 64 KB bringt es maximal für größere Kopieroperationen auf einem schnellen Datenträger, welcher aber 'ne gewisse (scheiße, wie hieß das nochmal) "Sprungzeit" (z.B. bei der Festplatte, wo der Schreib-/Lesekopf erstmal rumwandern muß) braucht.
für Speicherkarten kommt es drauf an ... mit Nutzung der WindowsFileCache sind die Werte etwa genauso und ohne WFC hängt es von der Geschwindigkeit des Datenträgers ab ... da können sich dann auch mal 8 KB gut machen, da sonst die einzelnen Lese/-Schreibaktionen ziemlich lange dauern können.

Darum ist in meinem Filesplitte auch mal ausnahmsweise ein größerer Puffer drinnen, aber sonst nehm ich oftmals die 64 KB grenze der Windows Speicherverwaltung.
(diese kann zwar in 4 KB-Schritten Blöcke reservieren, aber diese nur in 64 KB-Schritten in unserem virtuellen Speicherraum verwalten)

[Angel4585]

Ab welcher Windowsversion gilt diese 64K Grenze?
Das ganze sollte nämlich auch unter Windows 2000 noch gut laufen :mrgreen:

[himitsu]

diese "entstand" im Grunde mit Einführung des WinNT-Systems ... also seit Windows NT und fast allen Nachfolgern (Serversysteme können da schonmal anders und mit größeren Werten aufwarten)

[Dezipaitor]

Mark Russinovich hat über die verbesserte Kopierroutine in Vista SP1 berichtet:
http://blogs.technet.com/markrussino...4/2826167.aspx

[Angel4585]

Naja das sollte halt auf allen Windows-Systemen seit Windows 2000 laufen.
Aber dass der Unterschied so groß ist zwischen 8K Blöcken und 64K Blöcken ist schon heftig :gruebel:

[himitsu]

nja, wenn z.B. der WFC seine Datein in 64-KB-Blöcken verwalten würde, dann sollte man ihn auch besser damit füttern, da er ja bei kleineren Stückchen erstmal den Fehlenden Teil von der Festplatte lesen, um sich einen ganzen Block zu basteln und dann die Einzelstücke auch jeweils zusammenzusetzen müßte, statt einfach nur den "fertigen" Block anzunehmen.

[Blup]

Wichtig ist auch mit welchen Parametern fFrom und fTo geöffnet werden.
Schließt man den Cache aus, kann das Schreiben auf bestimmten Medien ohne weiteres um den Fakto 100 langsamer sein.
Mit Cache reicht für otimale Geschwindigkeit eine Blockgröße von 8..16 KByte.

[himitsu]

langsamer ist es ohne Cache nicht unbedingt ... nur weil die Daten im Cache liegen und die Kopieroperation "fertig" meldet, ist es noch lange nicht fertig ... ihr kennt doch bestimmt die USB-Sticks, welche danach noch minutenlang rumblinken, weil der Cache ja noch geleert werden werden muß.

[Mavarik]

Hi!

Warum machst Du es nicht so?

Delphi-Quellcode:

Procedure  FileCopy(Source,Dest:String);
var
  OpStruc: TSHFileOpStruct;
  frombuf, tobuf: Array [0..128] of Char;
Begin
{$IFNDEF DLL}
  fillChar( OpStruc, Sizeof(OpStruc), 0 );
  FillChar( frombuf, Sizeof(frombuf), 0 );
  FillChar( tobuf, Sizeof(tobuf), 0 );
  StrPCopy( frombuf, Source );
  StrPCopy( tobuf, Dest );
  With OpStruc DO Begin
    Wnd:= Form1.Handle;
    wFunc:= FO_COPY;
    pFrom:= @frombuf;
    pTo:=@tobuf;
    fFlags:= FOF_NOCONFIRMATION or FOF_RENAMEONCOLLISION;
    fAnyOperationsAborted:= False;
    hNameMappings:= Nil;
    lpszProgressTitle:= Nil;
  end;
  ShFileOperation( OpStruc );
{$ELSE}
Messagedlg('Operation in DLL nicht mölich',mterror,[mbok],0);
{$ENDIF}
end;

Mavarik :coder:

[himitsu]

ich mag Fehlerbehandlungen und Rückgabewerte und unnötige Puffer müssen auch nicht unbedingt sein :stupid:
PS: 128-2 = 126 Zeichen sollten etwas kurz sein ... wenn, dann sollte der Puffer schon mindestens MAX_PATH+1 sein

Delphi-Quellcode:

Function FileCopy(const Source, Dest: String): Integer;
var
  OpStruc: TSHFileOpStruct;
Begin
  fillChar( OpStruc, Sizeof(OpStruc), 0 );
  With OpStruc DO Begin
    Wnd := Form1.Handle;  // oder Application.Handle oder Nil
    wFunc := FO_COPY;
    pFrom := PChar(Source + #0);  // da Liste mit #0#0 abgeschlosen wird
    pTo := PChar(Dest + #0);
    fFlags := FOF_NOCONFIRMATION or FOF_RENAMEONCOLLISION;
    fAnyOperationsAborted := False;
    hNameMappings := Nil;
    lpszProgressTitle := Nil;
  end;
  Result := ShFileOperation( OpStruc );
end;

im Notfall geht's auch so (aber Ersteres sollte schon gehn):

Delphi-Quellcode:

Function FileCopy(Source, Dest: String): Integer;
var
  OpStruc: TSHFileOpStruct;
Begin
  Source := Source + #0
  Dest := Dest + #0;
  fillChar( OpStruc, Sizeof(OpStruc), 0 );
  With OpStruc DO Begin
    Wnd := Form1.Handle;  // oder Application.Handle oder Nil
    wFunc := FO_COPY;
    pFrom := PChar(Source);
    pTo := PChar(Dest);
    fFlags := FOF_NOCONFIRMATION or FOF_RENAMEONCOLLISION;
    fAnyOperationsAborted := False;
    hNameMappings := Nil;
    lpszProgressTitle := Nil;
  end;
  Result := ShFileOperation( OpStruc );
end;

[Mavarik]

Zitat:

Zitat von himitsu

ich mag Fehlerbehandlungen und Rückgabewerte und unnötige Puffer müssen auch nicht unbedingt sein :stupid:
PS: 128-2 = 126 Zeichen sollten etwas kurz sein ... wenn, dann sollte der Puffer schon mindestens MAX_PATH+1 sein

OK Recht hast Du... Hab die routine aus einem alten Tool kopiert...
Das war glaube ich noch aus den Zeiten kurzer Dateinamen... 63 Path + 8+3

Mavarik :stupid:

[Blup]

Zitat:

Zitat von himitsu

langsamer ist es ohne Cache nicht unbedingt ... nur weil die Daten im Cache liegen und die Kopieroperation "fertig" meldet, ist es noch lange nicht fertig ... ihr kennt doch bestimmt die USB-Sticks, welche danach noch minutenlang rumblinken, weil der Cache ja noch geleert werden werden muß.

Das Problem mit Stick oder SSD (Solid State Drive) ist folgendes:
- man schreibt einen Block von 16KByte
- wenn die Datei schon Daten enthält, liest der Stick einen Block (z.B. 512KByte oder mehr)
- der Stick sucht sich den nächsten freien Block und schreibt den gesamten Block neu
- findet er keinen freien Block mehr, werden vorgemerkte Blöcke gelöscht (und das dauert)
- man schreibt den nächsten Block von 16KByte ...

Insbesondere bei Datenbanken ergibt das "interessante" Effekte.
Neben der Geschwindigkeit ist hier auch die Lebensdauer der Hardware fragwürdig.