Wenn ich den Profiler in Visual Studio verwende, um teure Funktionen aufzuspüren, habe ich gelegentlich gesehen, dass die meiste Arbeit in [clr.dll] endet. Das ist im Grunde genommen eine Blackbox, und ich frage mich, ob es einen Weg gibt, herauszufinden, warum es so viel Zeit dort verbringt.
Ich nehme an, dass clr.dll Dinge wie JIT-Kompilierung, Laden von Assemblys und Verwalten von Anwendungsdomänen, Garbage Collection, Reflektionen usw. behandelt. Aber es macht es wirklich schwierig zu sagen, welcher Code dafür verantwortlich ist, so viel Zeit zu verbringen. p>
Offensichtlich ist es ein anderer Code außer der Laufzeit selbst, der dafür sorgt, dass er so viel Zeit in der clr.dll verbringt. Wie also finden Sie heraus, welcher Code fehlerhaft ist?
Sie müssen wissen, welcher Teil Ihres Codes - der Code, den Sie bearbeiten und kompilieren können - der einzige Code ist, den Sie reparieren können - welcher Teil des Codes für einen wesentlichen Prozentsatz der Zeit verantwortlich ist.
Es ist nicht gut zu wissen, dass clr.dll viel Zeit in Anspruch nimmt, wenn Sie nicht wissen, welcher Teil Ihres Codes dafür verantwortlich ist.
Diese Information befindet sich in der Aufrufliste.
Wenn Sie eine Methode oder sogar eine einzelne Codezeile haben, die sich für einige Prozent der Zeit im Stapel befindet, z. B. 20%, ist sie für ungefähr diesen Prozentsatz der Zeit verantwortlich. Wenn Sie diese Codezeile irgendwie eliminieren könnten (oder es viel weniger Zeit benötigen), würden 20% der Gesamtzeit Null oder fast werden, was Ihnen einen Beschleunigungsfaktor von 1,0 / 0,8 gibt = 1,25 oder 25%
Wie finden Sie solche Linien? Dies ist die Methode, die ich verwende. Niemand behauptet, dass es schön ist, es sei denn, die Gesamtergebnisse werden geschätzt. Wenn es wiederholt angewendet wird, sind große Beschleunigungsfaktoren möglich .
Tags und Links .net visual-studio profiler