15
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 232602
Url: https://administrator.de/contentid/232602
Printed on: April 23, 2024 at 05:04 o'clock
15 Comments
Latest comment
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:
Viele Objekte bieten auch eine Dispose() Methode wenn sie nicht mehr gebraucht werden.
Grüße Uwe
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()
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
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
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
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 ?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.
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.
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!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.
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?
Zitat von @MarcoBorn:
nachfragen. Kann es ggf. daran liegen, dass man eine XLL nicht aus einer EXE heraus aufrufen kann?
meinst du mit XLL eine Excel Addin DLL? das hätte man wissen müssen.nachfragen. Kann es ggf. daran liegen, dass man eine XLL nicht aus einer EXE heraus aufrufen kann?
Ja, ein Excel XLL. Laut Doku bzw. Google sollen das ja auch DLLs sein.
