Freigabe von Objekten zeitaufwändig?

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1040572)

ReportMemoryLeaksOnShutdown prüft nur am Ende des Programmes nach, ob noch was im Speichermanager liegt undzwar kurz vor Freigabe des Speichermanagers ... zu diesem Zeitpunkt wurden schon alle Objekte freigegeben (abgesehn von den Speicherleckt und diese würden dann auch angezeigt) ... dieses hat also keine Auswirkung zu diesem Zeitpunkt.

Oft werden Objekte aber beim Beenden des Programmes freigegeben, und es wirkt dann so, als würde dieser Vorgang lange dauern. Habe ich bei meinen Hashmap-Tests festgestellt, wo ich zwischenzeitlich mal zigtausend Memoryleaks hatte... (keine Sorge, jetzt sind es 0, falls jemand die mal benutzen möchte :stupid:)

[himitsu]

Wenn es lange dauert, dann liegt es nicht an ReportMemoryLeaks, es sei denn es muß ein rießiger Report erstellt werden.

Aber wie gesagt, ohne nähere Kenntnis zu diesem Projekt/Code, kann man nur wild rumraten.

[NormanNG]

Also ich habe durchaus die Erfahrung gemacht, das FastMM zum Beenden eines Programmes viel Zeit brauchen kann. Vor allem, wenn alle Debugging-Option aktiv sind. Dann werden u.U. alle Memoryblöcke auf korrekte Freigabe etc. geprüft und das kann - vor allem bei vielen zuvor benutzten Objekten - etwas dauern... unabhängig davon, ob der Code noch Fehler hat oder nicht.

Versuch es doch einfach mal FastMM mit komplett deaktivierten Debugoptionen einzubinden.

[mjenke]

@himitsu:

Natürlich habe ich anfangs auch mal brav immer das erste Objekt aus dem Array freigegeben, den Rest nach vorne verschoben und dann das Array verkleinert. Das hatte ich aber irgendwann selbst schon gefunden und mich fleißig geschämt :-D

Tatsächlich lief das Zerstören so ab, dass ich immer das letzte Objekt des Arrays zerstöre und dann das Array verkleinere.

Delphi-Quellcode:

while Last do Drop.Free;

Wobei Last eine Funktion einer Container-Klasse ist, von der sich all meine Container ableiten. Sie aktiviert den letzten Eintrag des Arrays (setzt einen Positionszeiger) und liefert True, wenn Einträge vorhanden sind, bzw. False wenn nicht.

Delphi-Quellcode:

function TMyContainer.Last: Boolean;
begin
  Result := Length ( FEntries ) > 0;
  if Result then FPosition := High ( FEntries );
end;

Drop liefert den aktiven Eintrag des Arrays und entfernt ihn gleichzeitig aus dem Array (wobei alle nachstehenden vorgezogen werden, was nicht allzu dramatisch ist, wenn ohnehin der letzte Eintrag aktiv war).

Delphi-Quellcode:

function TMyContainer.Drop: TObject;
var
  i, j: Integer;
begin
  Result := nil;
  if FPosition <> -1 then begin
    for i := FPosition to High ( FEntries ) do begin
      if i = FPosition then Result        := FEntries[i]
      else                  FEntries[i-1] := FEntries[i];
    end;
    SetLength ( FEntries, High ( FEntries ) );
    if      Length ( FEntries ) = 0 then FPosition := -1
    else if FPosition > High ( FEntries ) then FPosition := High ( FEntries );
  end;
end;

Auf Deine Anregung hin gebe ich in einer Prozedur DestroyAllObjects nun alle verwalteten Objekte frei und setze dann die Array-Größe auf 0.

Delphi-Quellcode:

procedure TMyContainer.DestroyAllObjects;
var
  i: Integer;
begin
  for i := 0 to High ( FEntries ) do FEntries[i].Free;
  SetLength ( FEntries, 0 );
  FPosition := -1;
end;

Das bringt mir immerhin mit meinen Testdaten eine Zeitersparnis von beinahe 30 Minuten ein. Statt der 75-80 Minuten brauchte meine Anwendung heute morgen nur 49 Minuten.

Vielen Dank für den Hinweis!!!

:D
Matthias

[himitsu]

Kleine Änderung, die gleich mal 40% einsprat :-D
(Welches bei wenigen freizugebenden Objekten ja fast garnicht auffällt, sich aber in der Masse schon fast als expotentielle Auswirkungen zeigt)

Nun müßte man nur noch die anderen Bremsen finden. :stupid:

[jfheins]

Das klingt jetzt ein bisschen nach Quick 'n Dirty programmierung, aber wenn die Anwendung beendet wird, brauche ich doch eigentlich den Speicherplatz gar nicht mehr freigeben?
ich weiß dass das ein Speicherleck ist, aber wenn die Anwendung danach eh von Windows weggefegt wird ... ? :twisted:

Etwas anderes ist es natürlich, wenn da irgendwelche Netzwerkressourcen oder so exklusiv gesperrt sind.

Okay, um auch etwas anderes ins Spiel zu bringen: Wäre es möglich, dass viel Speicher reserviert wird, aber nur wenig gebraucht? Sodass dann vll. der unbenutzte Speicher auf die Festplatte ausgelagert wird, und das beim Freigeben lange dauert?

[mjenke]

@jfheins:

Dieses Freigeben passiert während der Laufzeit immer mal wieder. Es gibt Grenzen, an denen ich neue Bearbeitungsschritte einleite und dabei erstmal alles aufräume, was ich nicht mehr brauche. Übrigens handelt es sich nicht um Speicherlecks, denn die habe ich in tagelanger Kleinarbeit gemeinsam mit einem Kollegen aufgestöbert und eliminiert. Alle Objekte, die erzeugt werden, werden auch wieder freigegeben. Ansonsten würde die Anwendung es gar nicht mehr schaffen, bis zum Ende durchzuarbeiten - hatten wir leider alles schon :-D

[jfheins]

Okay, dann sit die Quick n Dirty Lösung natürlich nicht optimal...

hast du schonmal daran gedacht, einen Profiler mitlaufen zu lassen?

[franktron]

Zitat:

Zitat von mjenke (Beitrag 1040527)

Dennoch baut die Anwendung diese ganzen Objekte innerhalb weniger Minuten auf (3-4 Minuten)

Ich frage mich hier was du da treibst 3-4 Min Objecte zu erstellen wie viele sind das den.
Oder hast du noch eine Pentium 1 ?

[mjenke]

Um noch eine letzte Rückmeldung zu geben - für den Fall, dass es noch einen interessiert - inzwischen ist auch die letzte Bremse beseitigt.

Kurzer Hintergrund: Die Anwendung plant an Hand von BoundingBoxen die Verteilung von Anzeigen innerhalb eines Katalogs. Dabei stehen verschiedene Anzeigen in einer Beziehung zueinander und müssen nach bestimmten Regeln auf gleichen, vorhergehenden oder nachfolgenden Doppelseiten platziert werden. Die Daten kommen als XML an, werden verarbeitet und es wird XML wieder weggeschrieben.

Um verschiedenste Umbruchvarianten durchzuprobieren, werden baumartig verschiedene Umbruchzweige geöffnet und die Anzeigen (da sie innerhalb jeder Umbruchvariante angepackt und mit Zusatzdaten versehen werden) geklont. Um es kurz zu machen: Die Anwendung klont wie wahnsinnig und erzeugt viele, viele, viele, viele Objekte.

Innerhalb des Klonens einer Anzeige gab es ein letztes Problem:

• Zu einer Anzeige gibt es Schnittkanten. Diese Schnittkanten geben vor, wo eine Anzeige zerteilt werden darf, um in mehreren Blöcken auf der Seite zu erscheinen
• Die Schnittkanten werden bei der Erzeugung des Objektes durch Analyse des übergebenen XML erzeugt

Also etwa:

Code:

TUmbrObjekt.Create ( XML: IXMLDOMNode );
begin
  [...]
  AnalyzeXml ( XML );      // Analyse des uebergebenen XML
  [...]
end;

Die Methode AnalyzeXML ist dann dafür zuständig, dass die entsprechenden Unterobjekte, welche die einzelnen Schnittkanten repräsentieren, erzeugt werden.

Grob gesagt (handelt sich hier um eine extreme Vereinfachung) habe ich also ein Objekt folgenden Aufbaus:

Code:

TUmbrObjekt = class
  [...]
  private
    FXML: IXMLDOMNode;   // Hier wird das XML der Initialisierung vorgehalten
    FSchnittkanten: Array Of TSchnittkante;
  [...]
end;

Das Objekt kann sich selbst aber auch klonen. Und dabei bin ich folgendermaßen vorgegangen:

Code:

function TUmbrObjekt.Clone: TUmbrObjekt;
var
  i: Integer;
begin
  Result := TUmbrObjekt.Create ( FXML );
  for i := 0 to High ( FSchnittkanten ) do begin
    // self.FSchnittkanten[i] an Result anhängen
  end;
end;

Und genau darin lag der Fehler: Sowohl im Create werden Schnittkanten durch das XML erzeugt, als auch während des Klon-Vorgangs zusätzlich noch einmal an den Klon angehängt. Auf diese Weise habe ich die Anzahl der Unterobjekte explosionsartig vermehrt.

Nachdem ich das aufgeräumt hatte, konnte ich die Bearbeitungszeit dramatisch verkürzen. Aus den ursprünglichen knapp 80 Minuten wurden bei gleichen Daten 1,5 Minuten. Mit dem Gesamtdatenbestand, der letzten Endes einen Katalog von etwa 800 Seiten erzeugt, schrumpfte die Bearbeitungszeit von über 4 Stunden auf 5 Minuten.

Vielen Dank für die Hilfe!!!!

:-D