Speicherlecks mit Dataobjects

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Antworten
Benutzeravatar
Schubi
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 139
Registriert: Mi, 05. Okt 2005 15:10
Wohnort: Wiesloch
Hat sich bedankt: 5 Mal

Speicherlecks mit Dataobjects

Beitrag von Schubi »

Hallo zusammen,

eine Frage in die Runde, ob jemand vergleichbare Probleme hat, bzw. das hier geschilderte Problem nachvollziehen kann:
Bei der Verwendung von Dataobjects mit :copy() bleiben Memoryhandles hängen.
Ebenso wenn man ein Dataobject mit Var2Json() exportiert.
Wir verwenden in unserer Anwendung vermehrt diese Funktionalität, das bedeutet, dass im Laufe des Tages immer mehr Handles verbraucht werden und das Programm immer langsamer wird.
Anbei ein Codeschnipsel, welches das Problem verdeutlichen soll:

Code: Alles auswählen

PROCEDURE main()
   LOCAL oData, oData2
   LOCAL nCount := 1
   LOCAL nLoop := 1000

   DllLoad("memwatch.dll")

   ? "Loading Memwatch"
   Sleep(500)


   ? "Starting Simple-Test"
   WAIT

   DO WHILE nCount <= nLoop
      oData := DataObject():new()
      oData := NIL
      Sleep(1)
      nCount++
   ENDDO

   ? "Done"

   nCount := 1
   Sleep(10)

   ? "Starting Var2Json-Test"
   WAIT

   DO WHILE nCount <= nLoop
      oData := DataObject():new()
      Var2Json(oData)
      oData := NIL
      Sleep(1)
      nCount++
   ENDDO

   ? "Done"

   nCount := 1
   Sleep(10)

   ? "Starting Copy-Test"
   WAIT

   oData := DataObject():new()

   DO WHILE nCount <= nLoop
      oData2 := oData:copy()
      oData2 := oData2
      oData2 := NIL
      Sleep(1)
      nCount++
   ENDDO

   ? "Done"

   nCount := NIL
   Sleep(10)

   WAIT
RETURN
Hat jemand ähnliche Problem bzw. gibt es einen Workaround?
Einen passenden PDR habe ich zu meinem Erstaunen nicht gefunden.
Wir setzen das aktuelle Builds 1079 ein, mit Build 951 ergab der Test jedoch das Gleiche.
D.h. dass das Problem schon seit mehr als einem Jahr existieren muss.
Grüße Steffen
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Speicherlecks mit Dataobjects

Beitrag von Jan »

Hallo Steffen,

ich arbeite selber recht viel mit DataObjects. Kann das aber bislang nicht bestätigen. Ich schau mal, ob ich das übers Wochenende austesten kann.

Ist das bei Dir ein Tippfehler? Die aktuelle Version ist die 1127, nicht die 1079.

Mit dem jetzt kommenden Udapte soll ein anderes Speicherleck geschlossen werden, im HTTPClient()

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Speicherlecks mit Dataobjects

Beitrag von Manfred »

Der GC kommt nicht mit. Ich hatte das gleiche Problem. Du solltest Dir vorher ein leeres DO anlegen und dann den Inhalt immer wieder tauschen und dann clonen.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Schubi
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 139
Registriert: Mi, 05. Okt 2005 15:10
Wohnort: Wiesloch
Hat sich bedankt: 5 Mal

Re: Speicherlecks mit Dataobjects

Beitrag von Schubi »

Hallo Manfred,

was meinst du mit clonen? Das wäre ja die :copy() - Methode. Aber gerade die macht ja das Problem.
Ohne :copy() gibt es kein Problem.
Der GC kann es eigentlich nicht sein: Selbst wenn du überall Sleeps() reinmachst, schaukeln sich die Handles hoch.
Grüße Steffen
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Speicherlecks mit Dataobjects

Beitrag von Manfred »

Sorry, ich meinte copy().
Aber das Problem dürfte das immerfortwährende dataobject():new() sein. Das hatte ich auch. Ich habe vor der Schleife einmal ein DO erzeugt und dann immer nur die jeweiligen Inhalte ausgetauscht und dann :copy() gemacht. Danach war Ruhe im Karton.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Schubi
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 139
Registriert: Mi, 05. Okt 2005 15:10
Wohnort: Wiesloch
Hat sich bedankt: 5 Mal

Re: Speicherlecks mit Dataobjects

Beitrag von Schubi »

Hallo Manfred,
nein, jedes Object neu erzeugen, macht keine Probleme, es ist nur langsamer.
Nur bei :copy() erhöhen sich die Memoryhandles.
Und bei Var2Json(): Das ist das größere Problem, da man das nur mit größerem Aufwand über Ot4Xb oder xb2.Net anders lösen kann.
Grüße Steffen
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Speicherlecks mit Dataobjects

Beitrag von Manfred »

ok,
war eine Vermutung. Bei mir ging das Tempo drastisch in den Keller. Deshalb habe ich es umgestellt und danach war ers wieder schnell.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Speicherlecks mit Dataobjects

Beitrag von ramses »

Hallo Steffen

leider hatte ich mit den Data-Objekten auch meine Sorgen. Ich habe mich dann entschlossen ohne diese weiter zu Arbeiten. Damit waren die Probleme dann auch vollständig beseitigt.
Valar Morghulis

Gruss Carlo
Antworten