@Haudruferzappeltnoch Mit jedem Button_Click erstellst Du eine neue Instanz Deines Dialogs.
Wenn Du möchtest, dass dur genau eine Instanz erstellt werden soll, dann mach es so:

@Haudruferzappeltnoch Bei diesem Codew ist nix zu sehen.
Kannst Du ein kleinbes Beispielprojekt machen, das den Effekt reproduziert?
====
Du greifst mit Form1.DS1.dtprint auf Daten zu.
Ich nehme mal an, dass Form1 der Name der Form ist, und solit die VB6-Kompatibilitäts-Instanz.
Wenn Du die Tabelle im Konstruktor übergibst, arbeitest Du nur auf einer Instanz:

@Haudruferzappeltnoch Tut mir Leid, ich kann es zwar reproduzieren, aber abhelfen kann ich nicht.
Ich hab es mit modalem Aufruf probiert, und wenn ich nach dem End Using ein GC.Collect(0) einfüge, steigt der Verbrauch nicht mehr an.
Das kann allerdings nicht die Lösung sein!

@Haudruferzappeltnoch Ich sprach vom modalen Aufruf des Dialogs:
Ja, GC ist der Garbage Collector, den zu bemühen sollte hier eigentlich nicht erforderlich sein!

Spekulatius: Der GarbageCollector sieht einfach keine Notwendigkeit darin, diese kleinen, nicht mehr gebrauchten Objekte/Formleichen zu entsorgen. Bei 10 MB RAM-Belegung durch die App gähnt der GC wohl nur müde und denkt sich: ›Komm wieder und weck mich, wenn es um 1 GB geht.‹

Der GC muss nunmal, wenn er etwas aufräumen möchte, deine Anwendung einmal komplett anhalten, sich alles ansehen, entscheiden was noch Kunst ist oder doch schon weg kann, und dann die Ausführung des Programmes fortsetzen. Daher versucht .NET den GC so selten wie nötig anzustoßen. Gerade in der jetzigen Zeit wo sogar die PCs normalsterblicher 8-16 GB RAM aufweisen ist, wenn gerade nichts weiteres läuft, 10 MB nicht würdig, um einen evtl. merklichen stotterer in deinem Programm zu erzeugen. Daher kann ein Programm schonmal etwas anwachsen bevor der GC aktiv wird.

Gleichzeitig muss man aber auch aufpassen, dass diese kleinen Anstiege im RAM-Verbrauch nicht tatsächlich RAM-Lecks sind. Der GC kann eben auch nur dann aufräumen, wenn nichts mehr auf ein Objekt verweist. Hast du also noch irgendwelche Referenzen in deinem Code auf ein Objekt (oder Unterobjekt), so darf der GC das nicht aufräumen. Da hilft dann auch kein GC.Collect() mehr.

Ich denke nicht. Da muss schon ein ziemlicher Brocken rumschwirren. Wenn da immer nur Krümel unentsorgt bleiben, wirst Du das wohl nicht großartig mitbekommen. Klar, wenn man einen Startwert der RAM-Belegung von 5 MB hat, im Laufe der Zeit auf 20 MB hochgeht und mit GC.Collect nur wieder auf 10 MB runterkommt, kann man vermuten, dass da noch irgendwas Unaufgeräumtes rumschwirrt. Aber da wäre es wohl besser, sich von der Codeanalyse unterstützen zu lassen, die darauf (falls richtig eingestellt) hinweist, wenn Objekte verwendet werden, die Dispose implementieren aber möglicherweise nicht disposed werden.

Haudruferzappeltnoch schrieb:

gar nicht schlecht

Doch.
Ich verwende in einem einzigen Programm GC.Collect() zum Aufräumen des Speichers während eines Live-Bildes einer Kamera, und da werden größere Datenmengen bewegt.
Bei Deinen "paar Bytes" sollte dies nicht erforderlich sein.
Lies doch mal selbst in einer Schleife den Speicher aus, wenn sich der Dialog nach einer sehr kurzen Zeit (Timer) selbst beendet und gib die Werte im MainWindow aus.
Vielleicht ist das ja auch eine Macke des Studios.

RodFromGermany schrieb:

Ich verwende in einem einzigen Programm GC.Collect() zum Aufräumen des Speichers während eines Live-Bildes einer Kamera, und da werden größere Datenmengen bewegt.

Und selbst da zweifel ich an, dass GC.Collect() was bringt.
Hast du belastbare Tests, die aufzeigen, dass dein GC.Collect() tatsächlich zu einer Entlastung des Systems führt, im Vergleich zum Zustand, wenn man den GC seine Arbeit einfach machen lässt?

Ansonsten habich das auch iwo aufgeschnappt, dass es Testing-Szenarient gibt, wo GC.Collect() sinnvoll ist.
Aber eben für Tests - nicht für laufenden Betrieb.

Welche Windows-Version nutzt du?

Ab Vista gibt es eine sogenannte Prefatch-Funktion des Arbeitsspeichers. Das heißt, alles was Windows benötigt oder auch der Anwender häufiger startet, wird schon vorher in den RAM geschrieben, damit diese Programme schneller geladen werden können.
Seit Windows 7 gibt es nun einen optimierten Arbeitsspeicher, der sich etwas anders verhält als die vorherigen Versionen. Vorher galt: Wird ein Programm nicht mehr benötigt, wird der Arbeitsspeicher entsprechend befreit.
In der neuen Version läuft das Speicher nun einfach voll. Wenn ich Speicher allociere, dann wird er reserviert. Wenn ich den Speicher dann freigebe, wird der Speicher nun nicht mehr befreit, sondern er wird als reserviert gekennzeichnet. Dies hat den Vorteil, dass wenn man ihn nochmal brauchen sollte, er sofort wieder zur Verfügung steht. Es wird (ähnlich wie bei SSDs) erst der weitere freie Speicher verwendet. Erst wenn hier der gesamte Speicher zu klein wird, wird der reservierte Speicher wirklich befreit und zur Verfügung gestellt. Laut MS soll sich auch der GC mehr auf diese Momente konzentrieren. Man kann es sehr schön im TaskManager sehen, dass meist mehr Speicher in Verwendung ist als Prozesse tatsächlich benötigen. Im Ressourcenmanager sieht man dann auch, dass ein Großteil davon nicht wirklich verwendet, sondern reserviert ist.

Ich kann mir also vorstellen, dass hier das Speichermanagement bei dir greift und erst weiterer freier Speicher für ein neues DGV verwendet wird und erst wenn dein Speicher vollgelaufen ist, anderer, nicht mehr referenzierter Speicher befreit und anschließend neu befüllt wird.

ErfinderDesRades schrieb:

Und selbst da zweifel ich an, dass GC.Collect() was bringt.

Bei so was bei 30 FpS und 4000x3000 Mono-Pixeln, das war bei der Demo-Ansteuerungs-Software dabei, und ich habe mit den Leuten gesprochen.
Mit Collect() lief es ruhiger.

Haudruferzappeltnoch schrieb:

Das heißt zum Testen auf solche Lecks wäre GC.Collect gar nicht schlecht?

Zum Testen auf RAM-Lecks gibt es seit mind. VS 2019 (kp. ob auch schon VS 2017 den hatte), einen Profiler, der dir haargenau aufzeigen kann, welche Objekte deines Programmes wie viel Speicher benötigen. Dazu legst du einen ersten Snapshot an, erledigst die Operation, von der du denkst, sie lässt keinen RAM frei, und machst dann einen weiteren Snapshot. Praktischerweise wird beim aufzeichnen eines Snapshots automatisch der GC angeworfen, sodass du auch wirklich nur die Objekte siehst, die tatsächlich noch "relevant" sind. Hast du also zwischen zwei Snapshots nen Anstieg an Objekten im RAM, kannst du nachsehen wo die herkommen.

@ErfinderDesRades Ich hatte nun einmal das Problem, dass ich innerhalb einer do-while Schleife, wiederholt Daten von einem Server lade, und in eine Datenbank schreibe. Das können, je nach Tabelle bis zu mehreren Hundert MB sein. Nun handelte es sich hierbei um eine App und RAM ist in dieser Umgebung ein begrenztes Gut. Leider ist der GC innerhalb der Schleife nicht angesprungen, weswegen manche Geräte dann in eine OutOfMemory Exception gelaufen sind. Ein GC.Collect() hat dem Abhilfe geschaffen.