File IO mit dem Windows-API?

[HHick123]

Hallo Leute, gerade bin ich dabei, meine FileIO-Unit (WindowsXP, Delphi6, Turbo Delphi 2006), die ich in meinen Projekten einsetze, aufzupolieren, um den Programmablauf zu beschleunigen (vor allem für eine Simulation, die einige Tage läuft, und intensiv auf der Platte herumfuhrwerkt - einerseits soll's schneller gehen, andererseits tut mir die Platte leid).

Ich bin zumindest schon so weit, dass ich die Files in möglichst großen Portionen auf die Platte schreibe (z.B. mit Blockwrite), bzw. typisierte Dateien verwende, und in möglichst großen Portionen schreibe/lese. Das war schon mal ein großer Fortschritt.

Aber jetzt hab' ich mir das Tool "File Monitor" von Mark Russinovich (sysinternals) downgeloaded, wo man sehr gut mitschauen kann, was passiert.

Und: Ich kieg' die Kriese!!!!
Mein Code kann noch nicht optimal sein! Permanent sieht man auf low-level-Ebene, CLOSE gefolgt von OPEN für das gleiche File (diese korrespondieren NICHT zu reset/close auf high-level-Ebene. Dann werden Fileattribute, die ich setze (und die meiner Programmlogik damit bekannt sind), sofort danach, bei der nächsten Funktion der high-level-Ebene wieder abgefragt.
-> Alles in allem SEHR SEHR viel unnötiger Overhead.

Daher meine Frage:
Kann man den Filezugriff nicht etwas low-levelliger machen, vielleicht direkt mit dem Windows-API??? Gibt's da ev. ein Tutorial?

Viele Grüße,
Helmut

[Bernhard Geyer]

Hast du evtl. einen Virenscanner laufen der dir u.U. dazwischenpfuscht?

[HHick123]

Ich hab' im "File Monitor" als Filter meine exe-Datei eingestellt, sodass ich nur meine eigenen Filezugriffe sehe. -> Virenscanner ist auszuschliessen.

Das sieht z.B. so aus:

Engine_E.exe:OPEN 0001SAA4.FEA SUCCESS Options: Open Access: 00100100
Engine_E.exe:SET INFORMATION 0001SAA4.FEA SUCCESS FileBasicInformation
Engine_E.exe:CLOSE 0001SAA4.FEA SUCCESS
Engine_E.exe:OPEN 0001SAA4.FEA SUCCESS Options: Open Access: 0012019F
Engine_E.exe:READ 0001SAA4.FEA SUCCESS Offset: 0 Length: 131072
Engine_E.exe:CLOSE 0001SAA4.FEA SUCCESS
Engine_E.exe:OPEN 0001SAA4.FEA SUCCESS Options: Open Access: 0012019F
Engine_E.exe:QUERY INFORMATION 0001SAA4.FEA SUCCESS Length: 8592
Engine_E.exe:READ 0001SAA4.FEA SUCCESS Offset: 0 Length: 8592
Engine_E.exe:CLOSE 0001SAA4.FEA SUCCESS

Das wäre dann z.B. am selben File:
OPEN-SETINFORMATION-CLOSE-OPEN-READ-CLOSE-OPEN-QUERYINFORMATION-READ-CLOSE

Ok, ich hab' mich ja noch nicht näher damit beschäftigt, aber mein Gefühl sagt mir, das das low-level-mäßig noch optimierbar ist...

Extrem ist z.B. ein Aufruf von "ForceDirectories"...

Viele Grüße,
Helmut

[HHick123]

Uuups, hab' gerade einen Fehler in meiner Programmlogik entdeckt, und zwar, dass ich das Read-only-Attribut in obigem Posting unnötigerweise auch für Files zurücksetze (mit SetFileAttributes), die ich eh' nur lesen will! Manchmal denk' ich erst beim Fragen nach .... Ok, ein Teil des Overheads ist von mir.....

Dennoch wär' ich sehr daran interessiert, wie der File-Zugriff auf der Ebene, die das Tool "File Monitor" anzeigt, zu realisieren wäre...

Grüße, Helmut

[p80286]

Hallo HHick123,

ich rate Dir Deine Zeit nicht damit zu verschwenden. Zu Zeiten von DOS und TurboPascal hat es noch richtig was gebracht daran zu drehen, ab windowsNT hab ich es aufgegeben Puffergrößen zu optimieren. Natürlich ist es kein Fehler Puffer mit der Größe Satzlänge*n zu nutzen, aber Windows weiß schon was gut für Dich ist. Im allgemeinen bist Du mit dem Tfilestream gut bedient. Das alte blockwrite hat manchmal Vorteile, aber umgekehrt gilt das auch und ich habe noch nicht herausbekommen woran es liegt. Die Unterschiede sind so gering, daß es sich auch nicht lohnt darüber zu grübeln.

Überprüf lieber Dein Programm ob Du Daten nicht mehrfach einliest, oder in zu kleinen Häppchen schreibst, da ist viel mehr herauszuholen.

Gruß
K-H

[gammatester]

Bist Du sicher, daß sich die IO-Aktionen nicht auf die Engine_E.exe selbst beziehen? ZB Resourcen laden etc? Da gäbe es dann auch nicht viel zu optimieren.

Gruß Gammatester

[Zacherl]

Jap entweder TFileStream oder manuell über die API mittels:

* CreateFile
* SetFilePointer
* WriteFile
* ReadFile
* CloseHandle

[HHick123]

Hi, nachdem ich jetzt in meiner Programmlogik noch Optimierungspotential gefunden habe, bin ich schon kleinlauter....

CreateFile etc. schau ich mir mal bei Gelegenheit genauer in der msdn an, sieht relativ kompliziert aus...

TFileStream klingt sehr interessant, hab' ich bis jetzt noch nicht benutzt...

I.a. handelt es sich bei mir um Files, die jeweils einen Datentyp hintereinander beinhalten, z.B. lauter smallints oder lauter singles. Momentan hab' ich meine Unit so geschrieben, dass das sie im interface Funktionen bereitstellt, um
- die Datei zu öffnen
- einen single/smallint/byte zu lesen (oder eof zurückmelden)
- die Datei schliesst.

In Wirklichkeit liest die Unit aber bei Bedarf einen ganzen Block (konfigurierbarer Größe) von smallints ein und gibt mit nur einen einzigen zurück, die anderen merkt sie sich fürs nächste mal.

Das Problem dabei ist aber: Wenn die Dateilänge nicht ein ganzzahliges Vielfaches der Blockgröße ist, mach ich das momentan so, dass ich die Datei schliesse, anders typisiert wieder öffne und den Rest einlese (bis vor kurzem noch byte für byte, aber das hab' ich mittlerweile auch schon verbessert, und lese in einem Rutsch den Rest ein). Trotzdem ist's noch nicht optimal.

Wie ist das mit TFileStream? Liest das "auf Vorrat" aus der Datei bzw. schreibt es einen ganzen Block auf einmal hinaus, auch wenn ich es hintereinander z.B. mit einzelnen singles füttere? Wenn ja, dann wäre das vermutlich ein guter Ersatz für meine ganze Unit...

Viele Grüße,
Helmut

[p80286]

Hallo HHick123,

ich hab da etwas aus meinen alten Beständen herausgekramt (ursprünglich TP mit blockread):

Delphi-Quellcode:

procedure PPADATENLESEN(efile:string);
const
  lies=128;
  sl=sizeof(tpsatz1);    {satzlänge=sizeof(tpsatz1)}
var
  pp      : tfilestream;
  buffer  : packed array [1..lies,1..sl] of byte;
  gelesen : integer;
  i       : integer;
begin
  erstpasatz:=nil;
  leztpasatz:=nil;
  pp:=tfilestream.create(efile,fmopenread or fmsharedenywrite);
   while pp.position<pp.size do begin
    gelesen:=pp.Read(buffer,lies*sl);
    for i:=1 to gelesen div sl do begin
      new(actpasatz);
      move(buffer[i],actpasatz^.satz,sizeof(tpsatz1));
      actpasatz^.next:=nil;
      actpasatz^.last:=leztpasatz;
      if erstpasatz<>nil then
        leztpasatz^.next:=actpasatz
      else
        erstpasatz:=actpasatz;
      leztpasatz:=actpasatz;
    end;
  end;{while-----------------------}
  pp.free;
end;

wahrscheinlich gibts in der Zwischenzeit elegantere Lösungen, aber das Teil funktioniert seit ein paar Jahren.

Gruß
K-H

[HHick123]

Danke, p80268, ausgehend davon hab' ich ein paar Experimente mit TFileStream gemacht.

Also, prinzipiell scheint TFileStream etwa das zu bieten, was ich suche.
Demgemäß hab' ich den Thread ev. in der falschen Rubrik (Windows API) gepostet.

Was ich bei TFileStream etwas schade finde, ist dass es eine "Eigenintelligenz" bezüglich der Größe der tatsächlich gelesenen Häppchen zu haben scheint, die für mich einerseits nicht ganz nachvollziehbar war, und andererseits aber anscheinend auch nicht so gut funktioniert, dass man sich die Bufferung im eigenen Programm überhaupt sparen könnte. Im speziellen: Wenn man z.B. byte für byte einliest, so greift er auch byte für byte auf die Platte zu, und liest nicht etwa voraus, was dann extrem langsam ist! Wenn man einen ganzen Buffer einliest, dann greift er unter umständen in anders großen Häppchen (z.B. einem größeren als der Buffer) auf die Platte zu, leider weiss man dann dabei aber nie genau, welche Buffergröße (ein Problem könnte sich z.B. ergeben, wenn ich eine extrem große Datei "ruckfrei" streamen möchte und TFileStream das "Häppchen" viel zu groß wählt)

Grüße,
Helmut