CreateFileW richtig verwenden

[Glados]

Ich bin in den Geschmack gekommen CreateFileW zu verwenden.
Jetzt stelle sich mir nur die Frage, wie ich das richtig verwende und die beste Performance raushole.

Aktuelle verwende ich es so

Delphi-Quellcode:

_Handle := CreateFileW(FileName, GENERIC_READ, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); // für Dateien zu lesen
// oder
_Handle := CreateFileW(FileName, GENERIC_WRITE, FILE_SHARE_READ, nil, CREATE_ALWAYS, 0); // für Dateien zu schreiben (zb blockwrite)

Kann man hier noch etwas besser machen?

[himitsu]

Was willst du besser machen?
Erstmal ist es "richtig" so, abgesehn von vielleicht "FileName" ... Wie ist das deklariert?

Nja, und was meinst du mit Performance,
bzw. was willst du erreichen?


Die API betreffend:
Non-Buffered (FILE_FLAG_NO_BUFFERING, FILE_FLAG_WRITE_THROUGH)
Asynchron (FILE_FLAG_OVERLAPPED)
Zugriffsmuster (FILE_FLAG_RANDOM_ACCESS oder FILE_FLAG_SEQUENTIAL_SCAN)

Ansonsten hat Performance erstmal rein garnichts mit CreateFile zu tun, sondern mit der Art des Zugriffs (was und wieviel wird wie gelesen/geschrieben), also prizipiell ist es egal oder CreateFile, TFileStream oder sonstwas.

Zitat:

Kann man hier noch etwas besser machen?

Zu 95% nein.
Und ansonsten hängt es von den Lese-/Schreibzugriffen ab, ob, wo und wie man was verbessern könnte.


Du hast doch natürlich schon lange die zum Thema gehörenden Dokumentationen gelesen und verstanden?
https://msdn.microsoft.com/en-us/lib.../aa363858.aspx > Caching Behavior

Wieso "Geschmack" und was ist deiner Meinung an CreateFile besser, als an TFileStream.Create, TFile.ReadXyz, TFile.WriteXyz und allem Anderen?
Denn die wenigen Zeilen da oben haben grunsätzlich erstmal keinerlei Vorteile, so wie sie sind.

[Luckie]

CreateFileW funktioniert genauso wie CreateFile. Wobei CreateFile ein Alias ist für CreateFileA bzw. CreaterFileW, je nach dem was man für einen Zeichensatz benutzt. Wobei CreateFileA von Windows intern nach CreateFileW gemappt wird. CreateFileA ist unter Windows mittlerweile nur noch eine leere Funktion.

Und was spricht gegen die Wrapper von der VCL? Warum alles von Hand machen? TFileStream. TMemoryStream. Stringlisten usw.

[Glados]

Zitat:

Non-Buffered (FILE_FLAG_NO_BUFFERING, FILE_FLAG_WRITE_THROUGH)
Asynchron (FILE_FLAG_OVERLAPPED)
Zugriffsmuster (FILE_FLAG_RANDOM_ACCESS oder FILE_FLAG_SEQUENTIAL_SCAN)

Genau das meine ich. Würdest du mir diese erklären und wann man was nutzt?

Wenn ich OPEN_EXISTING or FILE_FLAG_NO_BUFFERING statt OPEN_EXISTING verwende, ist der Zugriff 10x schneller.

Zitat:

Und was spricht gegen die Wrapper von der VCL?

Ich finde hier BlockRead und BlockWrite besser für meinen Fall.

[Neutral General]

Zitat:

Zitat von Glados (Beitrag 1380756)

Zitat:

Und was spricht gegen die Wrapper von der VCL?

Ich finde hier BlockRead und BlockWrite besser für meinen Fall.

Ist/Findest du es besser oder hast du nur keine Lust dir anzuschauen wie es mit TFileStream&Co geht? :P
Wäre nicht das erste mal dass sich Leute davor drücken weil sie "damals" CreateFile/BlockRead/BlockWrite gelernt haben ;)

[Glados]

Ich weiß so ungefähr wie TFileStream anzuwenden ist.
Aber warum nun vom alten Code weggehen, wenn er perfekt funktioniert und das sogar schnell :P

[Redeemer]

Zitat:

Zitat von Luckie (Beitrag 1380742)

Und was spricht gegen die Wrapper von der VCL? Warum alles von Hand machen? TFileStream. TMemoryStream. Stringlisten usw.

Man kann fmCreate und eins von den fmShare nicht gleichzeitig verwenden sondern muss sich für eins davon entscheiden. Sonst fallen mir keine Nachteile ein.

[himitsu]

Zitat:

Zitat von Glados (Beitrag 1380758)

Aber warum nun vom alten Code weggehen, wenn er perfekt funktioniert und das sogar schnell :P

Die neuen Klassen sind mindestens genauso schnell und dazu noch OOP.


Windows hat FILE_FLAG_RANDOM_ACCESS als Vorauswahl.
Wenn man Dateien sequentiell verarbeitet, dann kann man theoretisch Windows sagen, dass es den WindowsFileCache verwalten anpassen soll.
Wenn man aber keine Gigabyte oder mehr in der Datei umherschaufelt, hat es praktisch keinerlei spürbaren Einfluss.

Und gerade bei Non-Buffered wird es umstöndlich, da du dann nur noch in Schreib-/Lesevorgänge mit "ganzen" Sektoren (am Besten aber eher ganze Cluster und Verwaltungseinheiten in der WindowsFileCache) verwenden darfst, ansonsten knallt es.
Zugriffe auf kleinere Blöcke müsstest du dann erst mit einem eigenen Cache abfangen.
Der Witz ist, dass NonBuffered für kleine Dateien langsamer ist, da deine Anwendung auf das Ende der Operation warten muß und eben nicht den WFC verwenden kann, der standardmäßig immer aktiv ist.

[p80286]

Also so wie immer, solange Du weißt was Du tust, ist es egal was Du tust.
Nur wenn Du glaubst Du wüßtest was Du tust....:mrgreen:

Gruß
K-H

[Glados]

Ich glaube ich bleibe dann einfach bei obigen Zeilen.
Eine letzte Frage aber noch. Wo müsste ich FILE_FLAG_NO_BUFFERING einfügen, wenn ich es verwenden möchte?
Muss das durch FILE_ATTRIBUTE_NORMAL ersetzt werden?