msbuild.exe 4.6.1590.0 vs. 4.7.3062.0

Question

Hallo zusammen,

ich schreibe gerade an einem Programm für Umsatzabgrenzungen und Absatzstatistiken.

Das Programm läuft mit der msbuild.exe in der Version 4.6.1590.0 ohne Probleme mehrere Tage lang durch, wenn es die Auftragsdaten entsprechend bewertet. Mit der msbuild.exe 4.7.3062.0 allerdings habe ich bereits nach sehr kurzer Zeit das Problem, dass der Speicherverbrauch nach oben "schießt".

Die Code-Basis ist diesselbe. (Code-Basis ist VB.net.)

Das Problem tritt auf, egal, mit welchem Compiler ich das kompiliere (ob ich nun 4.6.1590.0 oder 4.7.3062.0 nehme, spielt keine Rolle)!

Wie kann es sein, dass sich die .NET-Laufzeit-Umgebung dermaßen unterschiedlich verhält? Wäre es theoretisch denkbar, dass es einen BUG im GC gibt?

Ein Gruß

Answer 1

Hi,

ohne Code kann man da nur wenig bis gar nichts sagen.

Du musst zuerst mal rausfinden, wo genau dein Speicherproblem auftritt. Helfen könnten dir dabei die Diagnosetools und der Leistungsprofiler von Visual Studio 2017.

Aber so nebenbei: Eine Anwendung, die mehrere Tage für irgendwelche Auswertungen läuft, ist zumindest überprüfungswürdig, wenn es nicht gerade um mehrere x Milliarden Datensätze oder mehr geht.

Hast Du die Anwendung evtl. im Debugmodus kompiliert? Falls ja, ändere das mal auf Release. Debug Builds können um Faktor 10 oder mehr verlangsamt laufen.

Natürlich ist ein Bug im GC oder auch woanders immer denkbar. Aber viel wahrscheinlicher ist ein Bug in deinem Code, bspw. wenn Du Ressourcen, Streams, Bitmaps, ... nicht mehr freigibst.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

Answer 2

Hallo Stefan,

vielen Dank für deine Antwort. Es ist mit Sicherheit so, dass es ein sehr "individuelles" Problem ist... trotzdem finde ich es spannend, dass sich die JIT-Laufzeitumgebung in zwei unterschiedlichen Versionen komplett anders verhält... und das mit demselben Kompilat. :(

Die Laufzeitdauer der Antwendung basiert selbstverständlich auf Grund der Selektionsmenge der Daten, ob ich nun das komplette Jahr, zwei Jahre oder nur einen Monat und dann auch noch standortbezogen in den Programmlauf gehe.

Die Diagnosetools und der Leistungsprpofiler sind mir bekannt, ich habe die Anwendung damit nun auch mal in der entsprechenden Umgebung getestet. Es scheint sich um "Speicherleaks" zu handeln, die nicht mehr freigegeben werden. (Ich habe eine ODBC-Schnittstelle in Verwendung, die in die COM-Welt "abdriftet".)

Das Release- oder Debug-Kompilat verhalten sich an dieser Stelle beide identisch.

Ich habe bereits die einzelnen Codeteile meines Programms voneinander getrennt getestet und die Laufzeit überprüft... es kommt im "Rohzustand" zu keinen Speicherüberläufen. Ich bin sogar den Code mehrmals durchgegangen und räume auch mittlerweile alles "sehr explizit" auf.

Ich habe das Gefühl/den Verdacht, dass es irgendwas mit den Kontextwechseln zu tun hat... aber auch hier ist mein Code eigentlich "sauber".

Gruß

Answer 3

Hi,

wenn ich wüsste, was Du mit "Kontextwechseln" meinst, könnte ich dir dazu evtl. auch noch was sagen :)

Wenn Du das Problem bereits mit hoher Wahrscheinlichkeit nach auf die Datenbankzugriffe per ODBC eingegrenzt hast, poste doch mal die Details hierzu. Welche DB, welcher ODBC Treiber, wie sieht dein Code dort aus, welche Datenmengen werden hin und hergeschickt, usw.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport