Klasseneinteilung und Performance

Hallo Forum,
ich habe in VB.Net eine Dll geschrieben, die u.a. Excel und Word startet und zwischen diesen beiden Programmen Daten austauscht etc.

Das Tool braucht ca. 20 Minuten für einen Durchlauf und Excel bläht sich von 100.000k auf mehr als 800.000k RAM auf.

Ist es sinnvoller, die Funktionen jeweils in einzelne Klassen aufzuteilen oder alles in 1 Klasse zu packen? Sollte man Variablen eher lokal oder global definieren? Gibt es außer dem Setzen auf Nothing noch andere Möglichkeiten, den Speicherbedarf zu reduzieren?

Vielen Dank im voraus,
M. Born

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 232602

Url: https://administrator.de/forum/klasseneinteilung-und-performance-232602.html

Ausgedruckt am: 10.04.2025 um 21:04 Uhr

15 Kommentare

Neuester Kommentar

Hallo M. Born,
Da uns hier der Code fehlt ist eine Einschätzung in deinem Fall schwierig. Kommt halt sehr darauf an wie dein Code aufgebaut ist, da hat jeder seinen eigenen Stil.
Du hast aber die Möglichkeit die Garbage Collection manuell aufzurufen und damit unbenötigte Resourcen freizugeben:

GC.Collect()

Viele Objekte bieten auch eine Dispose() Methode wenn sie nicht mehr gebraucht werden.

Grüße Uwe

Hallo Uwe, danke fuer die schnelle Antwort.

Es gibt also keine generelle Empfehlung, welcher Weg besser bzw. performanter ist? Den GC werde ich mal einbauen, wird hoffentlich etwas bringen. Mein Code umfasst ca. 20 Funktionen und Prozeduren mit ca 1800 LOC, die ich zur Zeit in 2 Klassen aufgeteilt habe.

Viele Grüße,
M. Born

Mein Code umfasst ca. 20 Funktionen und Prozeduren mit ca 1800 LOC

das ist ja noch winzig

Ich denke es kommt eher darauf an wie viel Objekte du von den Klassen generierst. Wenn also oft neue Objekte dieser zwei Klassen erstellt werden wäre es sicher vorteilhafter sie aufzuteilen. Aber ich würde eher ein Augenmerk auf neu erzeugte Variablen in Schleifen werfen.

Grüße Uwe

Hallo Uwe,
ich nutze zum Zugriff auf die Office-Komponenten ein Tool namens Excel-DNA, das einen Versions-unabhaengigen Wrapper darstellt. So brauche ich mir um die Excel-Version des Nutzers keine Gedanken machen.

Mein Tool besteht aus einer Hauptfunktion, die die anderen jeweils aufruft. Alle Variablen werde am Ende der Funktionen auf Nothing gesetzt.

Viele Grüße,
M. Born

Dann wäre vielleicht mal ein Performance Monitoring deiner Applikation angedacht bei der du die Größen der Objekte und den Garbage-Collector überwachst. Mehr dazu steht hier:http://msdn.microsoft.com/en-us/library/ff647791.aspx (Abschnitt CLR and Managed Code)

Grüße Uwe

Danke für den Link. Ich schaue mir das mal an. Obwohl ich den GC mehrmals in die Hauptfunktion eingebaut habe, scheint es keinen Einfluss zu haben. Das Tool läuft gerade durch, ist aber schon wieder größer als 700MB.

Zitat von @MarcoBorn:
Danke für den Link. Ich schaue mir das mal an. Obwohl ich den GC mehrmals in die Hauptfunktion eingebaut habe, scheint es
keinen Einfluss zu haben. Das Tool läuft gerade durch, ist aber schon wieder größer als 700MB.

mehrfaces aufrufen hintereinander ist keine so gute Idee, das erledigt NET normalerweise automatisch, aber was macht das Tool denn so, wenn man fragen darf ?
Bzw. wo und wie nutzt du die DLL ? 700MB ist heftig...

Die DLL startet je 1 Word und Excel. In Excel wird eine Xlt geladen, die Buttons und Optionsfelder zur Steuerung hat. In Word wählt der Nutzer eine Datei aus. Diese wird zuerst auf gewisse Kriterien hinsichtlich der Struktur untersucht. Wenn alles okay ist, werden Teile der Worddatei nach Excel eingelesen. Dann werden, basierend auf den Worddaten in Excel Formeln generiert und die Zellen formatiert. All dies erfolgt in den 2 Klasen und 1800 LOC. In der späteren Weiterverarbeitung der Daten, die aber nicht so performancekritisch sind, stecken weitere rund 5k LOC.

Da ich gerade im Zug bin, kann ich den CLR Profiler erst später im Büro testen.

Der Profiler funktioniert leider nicht, da ich ja keine Exe erzeuge, sondern eine DLL. Auch den in SharpDevelop integrierte Profiler funktioniert nicht.

dann mach doch schnell eine exe draus, die die DLL einbindet ...

Wenn ich die Datei als Verweis in SharpDevelop einbinde, stürzt mir die IDE ab. In VS Express kann ich sie zwar einbinden, aber wenn aus der DLL heraus Excel gestartet werden soll, stürzt die Exe ebenfalls ab. Gibt es ev. auch Profiler, die direkt auf eine DLL zugreifen können?

Zitat von @MarcoBorn:

Wenn ich die Datei als Verweis in SharpDevelop einbinde, stürzt mir die IDE ab. In VS Express kann ich sie zwar einbinden,
aber wenn aus der DLL heraus Excel gestartet werden soll, stürzt die Exe ebenfalls ab.

Da stimmt dann aber etwas nicht, bzw. irgendwo wird da ein ganz grober Fehler in der DLL eingebaut sein, vermutlich deshalb auch der enorme Speicherverbrauch.... Sicherstellen das kritische Stellen mit Try...Catch Konstrukten abgesichert sind!
Hier hilft dir normalerweise der Debugger von VS.

Bist du Sicher das ExcelDNA hier nicht der Übeltäter ist ? lässt sich einfach feststellen, indem man stattdessen nur mal mit der lokal installierten Interop-Excel arbeitet.

Eine Try-Catch habe ich in jeder Funktion/Prozedur eingebaut. Ich verfolge regelmäßig die Diskussionen zu ExcelDNA auf dessen Newslist. Dort hat sich keiner über Probleme in diese Richtung aufgeregt. Ich werde dort aber auch noch einmal nachfragen. Kann es ggf. daran liegen, dass man eine XLL nicht aus einer EXE heraus aufrufen kann?