Da habe ich mich verguckt.
Edge-Webview2 ist ein Control zur Anzeige von Web-Inhalten, die die Chrome-Engine enthält.
Im Zusammenhang mit Zusatzkomponenten muss man bei der Verwendung von Objekt-Variablen halt höllisch aufpassen.
Ich weiß nun nicht, in welcher Art mit dem Steuerelement kommuniziert wird, aber wesentlich ist häufig, dass man Variablen auf Objekte die man nicht mehr benötigt nach Möglichkeit mit Dispose() freigibt und/oder auf NULL setzt.
Bei COM-Objekten muss man auf jeden Fall "Marshal.ReleaseComObject" zum Freigeben von Speicher anwenden.
https://learn.microsoft.com/de-de/dotnet/api/system.runtime.interopservices.marshal.releasecomobject?view=net-7.0
Dispose() kann man auch vereinfachen, wenn man Objekte nur kurzfristig benötigt:
using (var oVar = new MyObject()) { .... }
Dabei wird das Objekt auch freigegeben, wenn eine Exception ausgelöst wird.
Ebenso ist es auch, manchmal, erforderlich, sich von Events auch wieder zu trennen, denn diese Verbindungen verlängern ebenso die Lebensdauer wenn der Consumer noch länger lebt.
Also nach "Object.EventName += FunctionName;" nach der Verwendung auch wieder "Object.EventName -= FunctionName;" durchführen. Mit Lambdaausdrücken geht sowas nämlich nicht "Obejct.EventName += (s, e) => Tuwas());".
Wenn sich der Speicherverbrauch ausschließlich auf die Chrome-Engine (Edge) bezieht, kann es ebenso an extensivem Speicherverbrauch von JavaScript handeln.
Denn auch Javascript hält den Speicher fest, wenn Variablen außerhalb von Funktionsscopes nicht zerstört werden "var = undef;"
Bei der Verwendung von WebAssembly kann es ebenso zu diesem Verhalten führen.
Eine genau Analyse wann und wo Speicher verbraten und nicht wieder freigegeben wird lässt sich nur mit Profilern wirklich feststellen.
