C# Benötige Hilfe bei Programm Performance Optimierung

hashken

Grünschnabel
Hi,

ich sitze nun seit einiger Zeit schon vor einem Problem.

Momentan bin ich dabei mit eigenen Dateiformaten zu arbeiten. Was bedeutet das damit mit inbegriffen ist das ich mehrere Dateien auslese und sie zusammenschreibe in eine Datei.
In welcher Form möchte ich nicht weiter ausführen aber es bewegt sich im bereich der Cryptographie.

Nun das ist mehr oder minder unwichtig, der Punkt ist. Das mein Programm einfach sehr langsam wird. Ich weiß natürlich bereits wann und aus welchem Grund dies geschieht.

Und zwar ist es so, wenn ich viele kleine Dateien verarbeite sagen wir 100 Bilder von der Größe von 50 kb. Dann läuft es einwandfrei. Wenn ich viele Dateien verarbeite Sagen wir rar Dateien a gut 10 mb läuft es einwandfrei. Falls aber nun der zustand zustande kommt das ich kleine Dateien verarbeite und bei diesem Prozess dann eine Große Datei dazwischenkommt braucht danach nun die kleine Datei viel mehr Zeit um verarbeitet zu werden als voher. Und dieser zustand hält dann die Ganze Zeit an! Erst nach dem neustart des Programmes läuft es wieder normal...

Ich habe bereits den RAM in Verdacht gehabt und diesen beobachtet aber hatte sich nur um ungefähr 14 mb vergrößtert nach dem genannten ereigniss. Ich spielte die Garbage Collector Methode ein und löschte anschließend Manuell. Das Ergebnis war das ich immer noch da stehe wo ich vorher stand.
Natürlich könnte ich alle kleinen Dateien zuerst verarbeiten und dann erst die großen aber das ist ja nicht der Sinn der Sache, außerdem will ich nun auch gerne mal wissen ob es dafür auch eine Lösung gibt. Somit suche ich hier Rat.

p.s.: Pausen helfen da auch nix wie gesagt der Status lässt erst wieder ab wenn das programm neu gestartet wurde. Wird eine Datei anschließend aufgerufen die zum verarbeiten mehr Zeit benötigt, weil sie Größer ist, so werden alle kleinen Dateien nur noch sehr langsam verarbeitet.
(So werden aus 150 Dateien in 30 Sekunden 150 Dateien in 10 Minuten!)


Ich hoffe ihr habt ein paar Ideen und | oder Ratschläge für mich.

Ich danke bereits im Vorraus.



-----------------------

Kleine erläuterung zum verarbeiten der Dateien

BinaryReader Normale Datei --> Evt. andere Prozesse die die Datei durchlaufen --> BinaryWriter/MemoryStream --> BinaryWriter schreiben der Datei zusammen mit den anderen Dateien mit dazugehörigen Daten in neue Einzelne Datei.



Ich hoffe ihr könnt mir helfen ansonsten werde ich die alternative packen müssen und alle großen Dateien an das ende des Prozesses legen.
 
Klingt seltsam. Rufst du die Close/Dispose-Methode deiner Reader/Writer auf nachdem du sie nicht mehr brauchst?
 
ja die close dispose methoden rufe ich auf (setze sie sogar = null und rufe manuell den gc auf, hatte auch nichts gebracht leider...)

im übrigen die hauptverarbeitung der Datei wird über aufruf einer dll die ebenfalls von mir in c# geschrieben wurde ausgeführt.

das ganze geschieht auch nur bei kleinen dateien sobald man eine große verwertet hat werden kleine nur noch sehr langsam abgearbeitet.

Den Backgroundworker hatte ich noch nicht ausprobiert werde mal gucken den zu implementieren.

Die abarbeitung in der reihenfolge ist eigentlich egal, das Programm ist bereits mit einer Fertigen Gui ausgestattet. Heißt die Dateien werden aus den List arrays gelesen. Und dann nacheinander abgearbeitet. Asynchrone Prozesse habe ich ausgrund der Performance ausgelassen da es sich wie gesagt in der Cryptographie bewegt und dabei bei einigen Sachen wie pack prozessen das ganze nur nacheinander funktioniert.


Das wirklich seltsame was mir noch aufgefallen ist das der Verbrauch des Programmes und die Prozessor auslastung komplett gleich bleibt auch wenn die Dateien auf einmal langsamer verarbeitet werden.
 
Zuletzt bearbeitet:
Da wir keinen Code sehen, wo du die Performance-Einbrüche vermutest, wird es sehr schwer sein, hier eine erfolgversprechende Antwort zu finden. Ich empehle dir daher mal den RedGate ANTS Memory/ ANTS Performance Profile zu versuchen. Beide sind auch als Trialeversion zu haben.
 
ahh moment ich hab visual studio 2010 ultimate da gibts auch nen leistungstest den probier ich dann auch mal aus, ich werde mal schauen

ich geb derweil schon einmal das cpu sampling ergebnis von dem visual studio test (ergab als ergebnis das der pack prozess also der gzip stream natürlich die ganze leistung aufbraucht war aber von vorne rein klar das ist ja auch nie das problem gewesen)

Aber deutlich zu sehen am diagramm ist es Bild1 gelb markierter bereich ist der erste durchgang wo alles schnell läuft Bild2 gelb markierter bereich ist zweiter durchgang wo eine große datei gelesen wurde und der fall erneut eintritt und nun ein deutlich anderes muster zu sehen ist un die kleinen dateien ab da langsam verarbeitet werden (zweiter durchgang hab ich abgebrochen nach einiger zeit)

Bild1:
http://img443.imageshack.us/img443/2310/rsgs.jpg

Bild2:
http://img338.imageshack.us/img338/5392/msgs.jpg


ich lade mir derzeit die von euch empfohlenen tools und mache weiterhin einen instrumental test und memory test und verwalteten memory test aus der visual leistungssuite

danke für eure mühen bereits
 
Zuletzt bearbeitet:
so den instrumentationstest erledigt:

hier sieht man wieder am ende steigt auf einmal der leistungsverbrauch enorm an
http://img685.imageshack.us/img685/6272/instrument.jpg


hier der verwaltete speicher, hier kann man sehr deutlich sehen das die kleinen dateien ohne probleme erst bearbeitet werden und dann im zweiten durchgang nach einer großen datei doch das verhaltensmuster stark anders ist...
http://img10.imageshack.us/img10/5575/netspeicher.jpg


und hier die paralelitätsuntersuchung, die scheint schon etwas mehr auszusagen, denn hier werden gleichzeitig konflikte aufgesammelt von gleichzeitig laufenden prozessen auffallend ist hier ab dem bereich also am ende der wieder dem zugeordnet ist wo die dateien langsamer verarbeitet werden sind ascheinend weitaus weniger kollisionen zu sehen...
http://img717.imageshack.us/img717/2186/kollision.jpg



habe nun auch die tools von euch getestet und das ergebnis ratlosigkeit. Es scheint einfach keinen Grund dafür zu geben warum dies so ist. Es scheint jedoch an der gzip methode aus dem framework liegen denn genau diese methode braucht nach besagtem ereignis mehr zeit für die kleinen Dateien...

Ich verwende durchweg using deriktiven zum sofortigen verwerfen der Daten.

Ich werde jetz versuchen den Gzip prozess kurzerhand einfach mal zuersetzen gegen eine externe .dll von sevenzip und | oder einen backgroundworker für den gzip prozess festlegen...


Ich schätze ihr habt da auch keine Ideen mehr.

Falls doch bitte sofort mir melden wäre da verdammt dankbar!

Immerhin weiß ich jetz (zumindest glaube ich es zu wissen) wo es hapert. Aber aus welchem spezifischem Grund weiß ich immer noch nicht.
 
Zuletzt bearbeitet:
Zurück