Announcement

**Andreas Kosch** · 07.06.2004, 12:16

Hallo,

>Ist es m�glich dass der Garbage Collector nicht richtig funktioniert?

Nein, der GC arbeitet genau so wie dokumentiert. Allerdings k�mmert sich der GC nur um den managed Code, alle direkten Allozierungen von nativen Win32-Handles etc. m�ssen wie gehabt in eigener Regie freigegeben werden. Tritt dieses Problem bei einer FCL-Anwendung (Windows Forms) oder bei einer VCL.NET-Anwendung auf?

>..wenn ich eine ASP.NET-Anwendung unter Delphi 8 erstelle.

Wird dort BDP.NET verwendet (d.h. werden diese Assemblies als Verweise ins Projekt eingebunden)? Wenn ja, hat das mit dem GC nichts zu tun, sondern mit einem Bug in BDP.NET. Das Speicherleck verschwindet sofort, wenn BDP.NET durch die originalen ADO.NET-Provider ersetzt wird

**M. Egger** · 07.06.2004, 12:27

Dieses Problem tritt bei einer VCL.NET-Anwendung auf. Ich verwende nur managed Code!
Ich erzeuge ein Formular, zeige es an und schreibe danach in das Objekt nil hinein:
<pre>
...
var
FormOjbect: TMyForm;
begin
FormOjbect:=TMyForm.Create();
FormOjbect.ShowModal;
FormOjbect:=nil;
end;
</pre>

Im Form werden Bilder geladen und angezeigt. 
Speicher vorm �ffnen: 33 MB 
Speicher nach �ffnen: 46 MB 
Nach dem Schlie�en des Formulars: 46 MB 

Beim ASP.Net verwende ich nur ADO.NET Datenprovider

**Andreas Kosch** · 07.06.2004, 13:52

Hallo,

>Dieses Problem tritt bei einer VCL.NET-Anwendung auf. 
>Ich verwende nur managed Code!

was n�tzt das, wenn VCL.NET am .NET Framework vorbei direkt aufs Win32 zugreift und intern das meiste von VCL.NET als unmanaged Code abl�uft?

>Beim ASP.Net verwende ich nur ADO.NET Datenprovider!

Wie sieht ein kurzes (!) Beispiel aus, mit dem sich dieser Effekt jederzeit reproduzieren l�sst? Wie viele CPUs stecken im Server (IIS)? In welchem Modus wird der GC betrieben (siehe .NET Framework Configuration | Eigenschaftn von My Computer | Radiobutton Garbage collection mode)

**M. Egger** · 07.06.2004, 14:31

>was n�tzt das, wenn VCL.NET am .NET Framework vorbei direkt aufs Win32 zugreift und intern das meiste von VCL.NET als unmanaged Code abl�uft?

d.h. Der Garbage Collector arbeitet bei den ganzen VCL.NET-Komponenten nicht richtig? Muss ich meine ganzen Formulare und alle Objekte selber freigeben?

>In welchem Modus wird der GC betrieben (siehe .NET Framework Configuration | Eigenschaftn von My Computer | Radiobutton Garbage collection mode)?

Garbage collection mode:
"F�r Benutzeranwendungen im Hintergrund ausf�hren"

>Wie sieht ein kurzes (!) Beispiel aus, mit dem sich dieser Effekt jederzeit reproduzieren l�sst? Wie viele CPUs stecken im Server (IIS)?

Dieser Effekt tritt aber nicht nur bei Datenbankzugriffen auf sondern auch bei anderen Seiten.
Es steckte eine CPU im Server

**Andreas Kosch** · 08.06.2004, 06:14

Hallo,

>..arbeitet bei den ganzen VCL.NET-Komponenten nicht richtig?

Es w�re juristischer Selbstmord zu behaupten, dass alle VCL.NET-Komponenten an dieser Stelle ein Problem haben ;-)

>Muss ich meine ganzen Formulare und alle Objekte selber freigeben?

Die Antwort auf diese Frage h�ngt mit beiden anderen Teilfragen zusammen. Wenn der Garbage Collector (GC) mit Hintergrund-Modus ("F�r Benutzeranwendungen im Hintergrund ausf�hren") ausgef�hrt wird, l�uft er unter Last in der Regel erst dann an, wenn eine neue Speicheranforderung nicht genug freien Speicherplatz vorfindet. Dann allerdings rattert die Festplatte erst einmal l�ngere Zeit. Wenn man dieses Verhalten nicht m�chte, muss man entweder den GC im Vordergrund betreiben oder freiwillig die nicht mehr ben�tigten (gr��eren) Objekte mit Dispose freigeben.

Immer dann, wenn man auf ein zuerst nicht erkl�rbares Verhalten st��t, w�rde ich folgendes machen: 
1. Zuerst in C# oder VB.NET nachpr�fen, ob dort das gleiche Verhalten auftritt. 
2. Wenn sich das Problem in C# oder VB.NET nicht reproduzieren l�sst, das Ganze in Delphi 8 mit einer FCL-Anwendung (Windows Forms) nachpr�fen. 
3. Wenn sich in der Delphi 8-FCL-Anwendung das Problem nicht reproduzieren l�sst, die VCL.NET-Anwendung solange abspecken, bis das Problem verschwindet. Im Worst Case verschwindet das Problem niemals :-(

>Es steckt eine CPU im Server

In diesem Fall muss sich der GC den einzigen Prozessor mit dem eigentlichen Programm teilen. F�r Serveranwendungen ist eine Mehrprozessor-Maschine (>= 2 CPUs) besser geeignet, da dann in der Voreinstellung der GC im Vordergrund auf der 2. CPU l�uft.

>..Im Form werden Bilder geladen und angezeigt.

Bei einem Test mit einem leeren VCL.NET-Formular, auf dem nur eine TTimer-Komponente liegt, ist kein Hochlaufen des Working Set des Prozesses zu beobachten (nach 100 Aufrufen ist das Working Set des Prozesses nur um 4 kByte gr��er geworden). Auch beim Grafik-Formular pendelt das Working Set zwischen 2 stabilen Grenzen. Allerdings lege ich aber "freiwillig" durch den Relaese-Aufruf den Zeitpunkt des Freigebens selbst fest, so dass der Speicherverbrauch erst gar nicht hochl�uft:

a) Hauptformular
<pre>
unit FormMain;
 
interface
 
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Borland.Vcl.StdCtrls, System.ComponentModel,
Borland.Vcl.ComCtrls;
 
type
TForm1 = class(TForm)
StatusBar1: TStatusBar;
EditCount: TEdit;
Label1: TLabel;
ButtonFormEmpty: TButton;
ButtonFormGrafik: TButton;
procedure ButtonFormEmptyClick(Sender: TObject);
procedure ButtonFormGrafikClick(Sender: TObject);
private
{ Private-Deklarationen }
public
{ Public-Deklarationen }
end;
 
var
Form1: TForm1;
 
implementation
 
uses FormEmpty, FormGrafik;
 
{$R *.nfm}
 
procedure TForm1.ButtonFormEmptyClick(Sender: TObject);
var
i, iMax : Integer;
begin
iMax := Convert.ToInt32(EditCount.Text);
for i := 1 to iMax do
begin
Form2 := TForm2.Create(nil);
try
Form2.ShowModal;
finally
Form2.Release;
end;
StatusBar1.SimpleText := i.ToString;
Application.ProcessMessages;
end;
end;
 
procedure TForm1.ButtonFormGrafikClick(Sender: TObject);
var
i, iMax : Integer;
begin
iMax := Convert.ToInt32(EditCount.Text);
for i := 1 to iMax do
begin
Form3 := TForm3.Create(nil);
try
Form3.ShowModal;
finally
Form3.Release;
end;
StatusBar1.SimpleText := i.ToString;
Application.ProcessMessages;
end;
end;
 
end.
</pre>
b) aufgerufenes leeres Formular
<pre>
unit FormEmpty;
 
interface
 
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, System.ComponentModel, Borland.Vcl.ExtCtrls;
 
type
TForm2 = class(TForm)
Timer1: TTimer;
procedure Timer1Timer(Sender: TObject);
procedure FormShow(Sender: TObject);
private
{ Private-Deklarationen }
public
{ Public-Deklarationen }
end;
 
var
Form2: TForm2;
 
implementation
 
{$R *.nfm}
 
{ TForm2 }
 
procedure TForm2.Timer1Timer(Sender: TObject);
begin
Close;
end;
 
procedure TForm2.FormShow(Sender: TObject);
begin
Timer1.Interval := 100;
Timer1.Enabled := True;
end;
 
end.
</pre>

c) aufgerufenes Grafik-Formular l�dt eine 385 kByte-Bitmap
<pre>
unit FormGrafik;
 
interface
 
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Borland.Vcl.ExtCtrls, System.ComponentModel;
 
type
TForm3 = class(TForm)
Image1: TImage;
Timer1: TTimer;
procedure FormShow(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
private
{ Private-Deklarationen }
public
{ Public-Deklarationen }
end;
 
var
Form3: TForm3;
 
implementation
 
{$R *.nfm}
 
procedure TForm3.FormShow(Sender: TObject);
begin
Timer1.Interval := 100;
Timer1.Enabled := True;
Image1.Picture.LoadFromFile('C:\Temp\D8TEST.bmp');
end;
 
procedure TForm3.Timer1Timer(Sender: TObject);
begin
Timer1.Enabled := False;
Close;
end;
 
end.
</pre>
Wird der Aufruf von Form3.Release durch Form3 := nil ersetzt, ballert man sich das Working Set des Prozesses bei 100 Aufrufen des Grafik-Formulars um 70 MByte zu. Es ist somit auch unter .NET in jedem Fall sinnvoll, derart gro�e Objekte freiwillig explizit (und somit zu einem definierten Zeitpunkt) freizugeben, wenn man derartige Zuw�chse nicht m�chte.
&#10

**M. Egger** · 08.06.2004, 09:03

>Es w�re juristischer Selbstmord zu behaupten, dass alle VCL.NET-Komponenten an dieser Stelle ein Problem haben ;-)

War ja nicht so gemeint *g*
 
Habe jetzt auch nochmals getestet. Ein Formular wird 50 mal aufgerufen und darin ein 783 KB gro�es Bitmap angezeigt und danach wieder geschlossen. Folgende Speicherauslastungen sind aufgetreten:
ohne Freigabe bzw. beim zuweisen von nil: 
83 / 83 MB mehr als vorm Aufruf(Speicherauslastung / Virtueller Speicher; lt. Taskmanager)
 
Bei Aufruf von Dispose:
9 / 8 MB mehr Speicherauslastung
 
Bei Aufruf von Release:
2 / 1 MB mehr Speicherauslastung
 
Ich bin das von Java so gewohnt dass ich die Objekte nur auf null setzen muss. Aber ich werde ab sofort gro�e Objekte explizit freigeben. 
Bei einem weiteren Versuch habe ich die Formulare nicht freigegeben und danach explizit den Garbage-collector aufgerufen (GC.Collect). Aber der Speicher wurde trotzdem nicht freigegeben. Deshalb muss ich annehmen dass der Garbage-Collector nicht richtig funktioniert. 
Weiters habe ich entdeckt dass wenn ich die das Formular minimiere, der Prozess nur noch 1 MB Speicher ben�tigt. D.h. der Speicher wird dann doch freigegeben (der Virtuelle Speicher ist noch immer gleich)

**M. Egger** · 08.06.2004, 10:33

Ich habe jetzt noch einen Test mit WinForms gemacht:
<pre>
procedure TWinForm.Button1_Click(sender: System.Object; e: System.EventArgs);
var
imageform: TWinForm1;
i: Integer;
begin
for i:=0 to 50 do
begin
imageform:=TWinForm1.Create;
imageform.Show;
end;
end;
</pre>
Hier gebe ich die Formulare nicht explizit frei. Folgende Speicherauslastung ergibt sich (Speicherauslastung / Virtueller Speicher; lt. Taskmanager): 
19,5 / 10,6 MB beim Starten des Programms 
100,9 / 51,3 MB nach der for-Schleife 
20,8 / 11,1 MB nach dem aufruf des Garbage-Collectors 
Hei�t das ich kann den Garbage-Collector bei VCL.NET-Anwendungen vergessen und muss alles h�ndisch freigeben

**Andreas Kosch** · 08.06.2004, 12:04

Hallo,

bei einer FCL-Anwendung oder einer C#- bzw. VB.NET-Anwendung ist die Sache einfach - das Programm greift direkt auf die Klassen/Komponenten aus dem .NET-Framework zu, so dass der GC st�ndig "im Bilde" ist (oder technischer gesagt, seine Listen mit den Objektreferenzen sind akkurat gef�llt).

Die VCL.NET ist kein Aufsatz auf die FCL (.NET Framework Class Library), sondern greift auf einem Nebenweg direkt auf Win32 zu (das ist ein Unterschied gegen�ber fr�her, wo die VCL nur ein Aufsatz auf das Win32 war). Somit muss man in der Tat st�ndig damit rechnen, dass der GC nicht immer feststellen kann, ob eine Objektinstanz noch gebraucht wird. Denn der GC r�umt eine Instanz erst dann ab, wenn keine andere Programmstelle darauf eine Referenz offen h�lt

**M. Egger** · 08.06.2004, 12:15

Hallo.

Dann kann ich ja einen sehr gro�en Vorteil von .NET mit VCL.NET (automatische Speicherverwaltung bwz. -freigabe) nicht wirklich benutzen und muss alles immer explizit freigeben. Damit laufe ich ja Gefahr gro�e Speicherleaks zu erzeugen. 
Da w�re es ja besser auf Delphi 7 zu bleiben (stabiler und schneller) oder unter Delphi WinForms zu programmieren oder �berhaupt gleich C# oder VB.Net zu verwenden. 
Ist es m�glich dass bei Delphi 9 VCL.NET auf die FCL aufsetzt, oder wird dieser eigenst�ndige Weg weitergef�hrt

**Andreas Kosch** · 09.06.2004, 05:51

Hallo,

>Ist es m�glich dass bei Delphi 9 VCL.NET auf die FCL aufsetzt...

Nein - dazu sind die Unterschiede zu gro�. Au�erdem hebt ja das Borland-Marketing die VCL.NET als Alleinstellungsmerkmal besonders hervor, da nur die VCL.NET auch zuk�nftig f�r eine enge Kundenbindung sorgt.

>...oder �berhaupt gleich C# oder VB.Net zu verwenden.

Es eher eine "Sowohl-als-auch"-Entscheidung. Ich greife seit l�ngerem f�r eine bestimmte Aufgabe immer zu dem Tool (Delphi 7, Delphi 8 oder VS.NET 2003), das f�r dieses konkrete Aufgabe am Besten geeignet ist. Bei meinen beiden letzten Projekten (Three-Tier-Datenbankanwendungen, die bundesweit �ber das WAN auf eine zentrale Datenbank zugreifen) besteht der COM+ Serverteil aus einem .NET Enterprise Service, der mit VS.NET 2003 in C# geschrieben wurde, aber die Clients sind noch Delphi 7 (Win32), die �ber DCOM auf den .NET Enterprise Service zugreifen.

Gerade die Wizards von VS.NET sind zum Beispiel im Datenbankbereich (falls der MS SQL Server verwendet wird) um Gr��enordnungen leistungsf�hige als bei der sonstigen Konkurrenz. In diesem Zusammenhang macht es selbstverst�ndlich nur dann Sinn, wenn auch in Delphi 8 nur die FCL genutzt wird, da dann alle Sprachen die gleiche Klassenbibliothek nutzen. Und da eine Anwendung in verschiedenen Sprachen geschrieben werden darf, sammelt sich im Laufe der Zeit eine eigene Tool-Sammlung in Gestalt von Assembly-DLLs an, die dann jederzeit von beliebigen Projekten eingebunden werden kann

**M. Egger** · 14.06.2004, 10:56

F�r ein ganz neues Projekt ist es also am sinnvollsten unter FCL zu programmieren, da die VCL.NET eigentlich nur beim portieren bestehender Anwendungen Vorteile bringt.

Ich habe f�r ein neues Projekt schon einiges in VCL.NET programmiert und komme jetzt immer mehr auf Fehler im Delphi 8 und auf Einschr�nkungen drauf. Zurzeit �berlege ich ob ich nicht auf Delphi 8-WinForm oder auf C# umsteigen soll, da mir das Visual Studio 2003 sehr stabil scheint

Announcement

Garbage Collector

Garbage Collector

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment