Daten auf Festplatte statt in Speicher schreiben

[Patrick]

Hallo,

Ich habe folgendes Problem:
Ich hab ein Programm geschreiben, dass Dateien einer Festplatte nach bestimmten merkmalen absucht und diese mit dem gesammten Pfad in eine CheckListBox und zusätzlich die Dateigröße in Byte in einen "Array of int64" schreibt.
Da ich dabei leider sehr viele Dateien ausgewählt werden, kann es sein, dass mein Programm mit der Meldung "Zu wenig Arbeisspeicher" (oder so ähnlich) beendet wird. Damit das nicht passiert will ich nun die Daten nicht in den Arbeitsspeicher schreiben, sondern auf die Festplatte, da dort gewöhnlich um einiges mehr Platz ist.
Wie mache ich das am Besten?

[Flips]

Hi.

Bist du sicher, dass dieser Speicherverbrauch vom Array ausgeht?
Laut meiner Rechnung (Int64 = 64 bit = 8 Byte) kann ein normaler User mit 512MB Ram WELCHER ER FREI HAT (nicht insgesamt) 67108864 Int64 Werte speichern.

Aber zu deiner Frage zurück. Könnte man das nicht mit einem TFileStream machen? Oder wird der auch im Arbeitsspeicher gepuffert?
[Edit]
Allerdings denke ich, dass das Puffern auf der Festplatte sehr große Performance-Einbußen mitsich bringt
[/Edit]

[Jürgen Thomas]

Tut mir leid für diesen Kommentar: Wenn Du mit einer Liste von Datei-/Pfadnamen und Dateigröße Probleme mit dem Arbeitsspeicher bekommst, dürfte ein ganz anderes Problem bestehen. Wieviel Arbeitsspeicher hast Du denn für Dein Programm - 512 kB?

Berechne doch einmal den benötigten Platz (natürlich äußerst großzügig, weil immer auch Pointer und Verwaltungsspeicher benutzt wird) und kontrolliere, wann und wo und wie oft Du Speicherplatz anforderst und freigibst. Ich vermute, hier hast Du etwas äußerst unpraktisch organisiert.

Vermutung: Bei der Suche mit FindFirst/FindNext ist der Record TSearchRec mit

Delphi-Quellcode:

FindClose(SearchRec);

freizugeben; und wenn Du das mit rekursiver Suche häufig vergisst...

Im übrigen können wir Dir vor allem dann helfen, wenn Du Deinen Versuch genauer angibst (mit Quelltext) und wenn Du selbst erläuterst, was Du bereits versucht hast.

Jürgen

[himitsu]

wie genau speicherst du denn die Daten,
also wie hast du deine atenstruckturen definiert?


ich habe es jedenfalls noch nicht geschaft den RAM voll zu machen und das selbst wenn ich die Daten einer gesamten Festplatte speichere (und da nicht nur den Namen und Dateigröße)

> siehe http://www.delphipraxis.net/internal...ct.php?t=95701



und vorallem wie verwaltest die diese Daten ... ich könnte mir da auch ganz gut eine Speicherdefragmentierung vorstellen (besonders der DelphiMM kann locker mal doppelt soviel Speicher verbrauchen, wie vom Programm reserviert wurde)

[Patrick]

Also das ist der ganze relevante Code

Delphi-Quellcode:

var resdatgro : array of int64;
procedure TForm1.ListFileDir(const Path, subdir, tage: string; FileList : TStrings);
var SR : TSearchRec;
    datum : TDateTime;

  function GetLastModified(const Datei: string; out Value: TDateTime): Boolean;
  var dt : Integer;
  begin
    dt := FileAge(Datei);
    Result := dt >= 0;
    if Result then
      Value := FileDateToDateTime(dt);
  end;

  function GetFileSize(szFile: string): Int64;
  var fFile : THandle;
      wfd   : TWIN32FINDDATA;
  begin
    result := 0;
    if not FileExists(szFile) then exit;
    fFile := FindFirstfile(pchar(szFile), wfd);
    if fFile = INVALID_HANDLE_VALUE then exit;
    result := (wfd.nFileSizeHigh * (Int64(MAXDWORD) + 1)) + wfd.nFileSizeLow;
    windows.FindClose(fFile);
  end;

begin
  StatusBar1.SimpleText:='Datei-Scan: "'+Path+'"';
  Application.ProcessMessages;
  if FindFirst(Path + '*.*', faAnyFile and faDirectory, SR) = 0 then
  begin
    repeat
      if ((SR.Attr and faDirectory) <> 0) and (subdir='ja') then
      begin
        if (SR.Name <> '.') and (SR.Name <> '..') then ListFileDir(Path+SR.Name+'\',subdir,tage,FileList);
      end
      else if (SR.Attr <> faDirectory) then
      begin
        GetLastModified(path+SR.Name,datum);
        if datum <(date-StrtoInt(tage)) then
        begin
          CheckListBox1.Items.Add(path+SR.Name);
          checkListBox1.Checked[CheckListBox1.Count-1]:=true;
          setlength(resdatgro,CheckListBox1.Items.Count);
          resdatgro[Checklistbox1.Items.Count-1]:=GetFileSize(path+SR.Name);
        end;
      end;
    until FindNext(SR) <> 0;
    FindClose(SR);
  end;
end;

Also bei wie vielen Elementen er letztendlich hängen bleibt muss ich erst testen, und dazu hab ich momentan wenig Zeit. Aber kann man die Funktion vielleicht Iterativ lösen? Rekursion hat eben Nachteile in der Rechenzeit und dem Speicherbedarf.

[Christian Seehase]

Moin Patrick,

das Problem dürfte sein, dass Du FileList als Wertparameter deklariert hast. Dann wird eine Kopie angelegt.
Schreib mal const davor.

Bei GetFileSize könntest Du das FindClose noch mit einem try/finally absichern (wenn auch hier nicht zwingend erforderlich), ausserdem halte ich den Default-Rückgabewert von 0 für ungeschickt, denn eine Datei kann ja durchaus 0 Byte gross sein.
Wie wäre es mit -1?

faAnyfile and faDirectory ist das gleiche wie faDirectory.

[EDIT]
Ach ja, in Deiner Hauptroutine fehlt ein Try/Finally um den Aufruf von FindClose abzusichern.
[/EDIT]

[himitsu]

Zitat:

Zitat von Christian Seehase

Bei GetFileSize könntest Du das FindClose noch mit einem try/finally absichern (wenn auch hier nicht zwingend erforderlich),

Könnte man, aber da FindFirstFile im Allgemeinen keine Exceptions auslößt, auch nicht nötig.
Aber FileExists ist unnötig, denn dieses greift intern ja wiederum auf FileAge zu, welches wiederum FindFirstFile verwendet.

Delphi-Quellcode:

function GetFileSize(szFile: string): Int64; 
var fFile : THandle; 
    wfd   : TWIN32FINDDATA; 
begin 
  result := -1; 
  fFile := FindFirstfile(pchar(szFile), wfd); 
  if fFile = INVALID_HANDLE_VALUE then exit; 
  result := (Int64(wfd.nFileSizeHigh) shl 32) or wfd.nFileSizeLow; 
  windows.FindClose(fFile); 
end;

Zitat:

Zitat von Christian Seehase

das Problem dürfte sein, dass Du FileList als Wertparameter deklariert hast. Dann wird eine Kopie angelegt.
Schreib mal const davor.

TStrings ist doch "nur" 'ne Klasse, sollte es da nicht nur 'ne Kopie der Klassenrefferenz ergeben
und nicht von den ganzen Daten in der Klasse? :gruebel:

Abgesehen davon wird FileList doch garnicht verwendet.
Ich würde da eher das Problem bei CheckListBox1 sehen.

Zitat:

Zitat von Patrick

Also bei wie vielen Elementen er letztendlich hängen bleibt muss ich erst testen

Das heißt also es gab noch keine Probleme mit dem Speicher?

Na ja, dann würde ich jetzt einfach mal Behaupen, daß es da so schnell auch keine geben wird,
aber wo es zum hängen kommen wird, ist vermutlich die Geschwindigkeit der ListBox.

Sieh es mal so, mein Programm hat 4 Dateilisten ... jeweils 2 für die Vergleichsdaten (wo nicht nur die paar Namen, Größen und Alter drin stehen), davon nochmals eine komplette Kopie (einmal in der Vergleichsklasse und im Programm) und dann nochmal ein weiteres Array für die ListView(Dateiliese).

Schau dir also mal sowas wie die "Virtual TreeView" von Soft Gems an.
(mein Vorgängerprogamm verwendete 'ne ListView, wo es schon mal weit über 5 Minuten zum füllen der Liste brauchte ... und die VTV ist schon nach unter einer Sekunde voll)


Was aber auch schon ein wenig Linderung verschaffen würde, wäre zumindestens ein BeginUpdate und EndUpdate,
dieses bring Prozentual zwar eine ganze Menge an Leistung ... aber es dauert effektiv dennoch recht lange, wenn Vieles in der ListBox geändert (hinzugefügt) wird.




PS: GetLastModified liefert vom Datum her das Selbe wie FileAge, also .ftLastWriteTime, was wiederum .Time im TSearchRec vom FindFirst entspricht.
TSearchRec.Time = GetLastModified

aber wenn du statt FindFirst gleich FindFirstFile verwendest, dann hast du alle 3 Werte (Name, Datum und Größe) auf Einmal :zwinker:

[Christian Seehase]

Moin himitsu,

Zitat:

Zitat von himitsu

Könnte man, aber da FindFirstFile im Allgemeinen keine Exceptions auslößt, auch nicht nötig.

stimmt, aber dabei geht es ja auch nicht um FindFirstFile, sondern um den Code, der zwischen einem erfolgreichen Aufruf von FindFirstFile und FindClose steht.

[himitsu]

Zitat:

Zitat von Christian Seehase

stimmt, aber dabei geht es ja auch nicht um FindFirstFile, sondern um den Code, der zwischen einem erfolgreichen Aufruf von FindFirstFile und FindClose steht.

Code:

function GetFileSize(szFile: string): Int64;
var fFile : THandle;
    wfd   : TWIN32FINDDATA;
begin
  result := -1;
  fFile := FindFirstfile(pchar(szFile), wfd);
  [b]if fFile = INVALID_HANDLE_VALUE then exit;
  result := (Int64(wfd.nFileSizeHigh) shl 32) or wfd.nFileSizeLow;[/b]
  windows.FindClose(fFile);
end;

Na ja, die beiden Zeilen sind schon recht "harmlos" :roll:

Wobei es so bestimmt auch recht "sicher" wäre :angel:

Code:

function GetFileSize(szFile: string): Int64;
var fFile : THandle;
    wfd   : TWIN32FINDDATA;
begin
  fFile := FindFirstfile(pchar(szFile), wfd);
  [b]windows.FindClose(fFile);[/b]
  if fFile = INVALID_HANDLE_VALUE then result := -1
  else result := (Int64(wfd.nFileSizeHigh) shl 32) or wfd.nFileSizeLow;
end;