Tracen von Funktionsein- und ausstieg mit System.Diagnostics.Trace

xhead_

Grünschnabel
Hallo zusammen,

ich beschäftige mich seit ein paar Tagen mit diversen Tracing-/Ausgabemöglichkeiten in .Net.
Das Tracing von System.Diagnostics finde ich bisher ganz passabel. Nur leider vermisse ich eine Funktionalität.
Ich möchte gern den Eintritt in eine Funktion und das Beenden der Funktion automatisiert Tracen. D.h. ich möchte nicht explizit am Anfang einen der Funktion einen Aufruf ala
Code:
Trace.WriteLine("Begin funktionXY()");
und am Ende bzw. jedem Aussprungspunkt
Code:
Trace.WriteLine("End funktionXY()");
aufrufen.

Ist sowas generell möglich mit System.Diagnostics.Trace? Wenn ja was muss mal dafür tun?
Falls nein, wie implementiert man sowas :rolleyes:?

Gruß
xhead_
 

Norbert Eder

Erfahrenes Mitglied
Du kannst hier mit PostSharp (AOP) arbeiten, was jedoch die Ausführungsgeschwindigkeit deiner Anwendung in diesem Fall schon drastisch senken kann/wird. Eine andere Möglichkeit ist das Verwenden entsprechender Tools, die dir die entsprechenden Informationen liefern. Anzumerken wären hier unter anderem der ANTS Profiler. Es gibt da aber auch weitere Tools, die ein Profiling zur Laufzeit ermöglichen.
 

xhead_

Grünschnabel
Das klingt sehr interessant.
Ich habe in der Zwishcenzeit eine eigene Lösung gefunden, die ich gegen die PostSharpverwendung antreten lasse.

Ich habe eine Traceklasse (heißt TraceHelper )geschrieben die von IDisposable erbt.
Im Konstruktor der Klasse trace ich das "Begin" und in der Dispose-Funktion das "Leaving".
Aufgerufen wird das ganze über ein using-Statement:
Code:
public void functionXY()
{
    using (TraceHelper aTrace = new TraceHelper("functionXY"))
     {
           //hier steht der Funktionscode            
     }
}

Innerhalb der Funktion kann ich über das TraceHelperobjekt weitere Traces erzeugen.

Ob diese Vorgehensweise "gut" ist stell ich hier mal zur Diskusion. Bis jetzt tuts das was es soll.
 

Norbert Eder

Erfahrenes Mitglied
Damit musst du es in jeder Methode implementieren, was nicht optimal ist und vermutlich läufts so dann wohl auch in der Release-Umgebung, wodurch du die Anwendungs-Ausführung schon verlangsamst. Ist das so gewollt?
 

xhead_

Grünschnabel
Das es auch in der Releaseumgebung mitläuft ist nicht so schlimm.
Die Verlangsamung der Anwendungsgeschindigkeit ist allerdings ein schwerwiegender Punkt. Aber langsamer wird die Anwendung so oder so. Egal ob ich eines der vorgeschlagenen Tools verwende oder meine Implementierung. Aber da werden mir die Performancetest, die jetzt anstehen schon Aufschluss drüber geben. Bin mal gespannt was da rauskommt.

Im übrigen finde ich es nicht so schlimm, dass man das Tracing mit meiner Methode für jede Funktion immer explizit "aktivieren" muss. So kann man steuern welche Funktionen und vor allem wieviel getracet werden soll.
 

Norbert Eder

Erfahrenes Mitglied
Was ist dein Ziel? Willst du an der Performance drehen oder willst du Performance-Daten ständig bei allen Installationen mitlaufen laufen? Im ersten Fall reicht ein Profiling-Tool und du hast keine permanente Performance-Verschlechterung.
 

xhead_

Grünschnabel
Primär geht es mir darum, dass ich den Eintritt und das Beenden von bestimmten Funktionen tracen will.
Die Performance ist dabei wichtig und soll nicht so arg unter den Traces "leiden". Mit Performancetests meinte ich allerdings Vergleiche zwischen PostSharp und meiner Implementierung hinsichtlich der Verlangsamung der Anwendungsgeschwindigkeit.
 

Norbert Eder

Erfahrenes Mitglied
Ja, aber willst du es laufend tun, oder um heraus zu finden, wie oft welche Methode aufgerufen wird und wieviel Zeit sie verbraucht, um diese zu optimieren?

Das ist nämlich genau der Punkt: Sprich, deine Variante (die du jetzt implementiert hast) mag in Ordnung sein, wenn du diese Infos laufend mitschreiben willst. Soll dies aber nur einmal oder von Zeit zu Zeit mal festgestellt werden, dann bist du mit einem Profiling Tool besser bedient.
 

Norbert Eder

Erfahrenes Mitglied
Dann hast du eh nicht viele Möglichkeiten und dein Ansatz sollte schon so passen, auch wenn ich es persönlich über AOP lösen würde.