Funktionsprofilfehler - Visual Studio 2010 Ultimate

Der "Hot Path" in der Übersichtsansicht ist der teuerste Aufrufpfad basierend auf der Anzahl der enthaltenen Samples (Samples von der Funktion und Samples von Funktionen, die von der Funktion aufgerufen werden) und exklusive Samples (Samples nur von der Funktion) ). Ein "Sample" ist nur die Tatsache, dass die Funktion an der Spitze des Stapels war, wenn der Treiber des Profilers den Stapel erfasst hat (dies geschieht in sehr kurzen Zeitintervallen). Je mehr Samples eine Funktion hat, desto mehr wird sie ausgeführt.

Standardmäßig ist für die Stichprobenanalyse eine Funktion mit dem Namen " Nur mein Code " aktiviert, die Funktionen auf dem Stack von Nicht-Benutzermodulen ausblendet (es wird eine Tiefe von 1 Nicht-Benutzerfunktionen angezeigt) falls von einer Benutzerfunktion aufgerufen, in Ihrem Fall Application.Run ). Funktionen, die von Modulen ohne geladene Symbole oder von Modulen stammen, von denen bekannt ist, dass sie von Microsoft stammen, würden ausgeschlossen. Ihr "Hot Path" in der Zusammenfassungsansicht zeigt an, dass der teuerste Stapel nichts von dem enthielt, was der Profiler als Ihren Code betrachtet (außer Main ). Das Beispiel von MSDN zeigt mehr Funktionen, da die Funktionen PeopleTrax.* und PeopleNS.* von "user code" kommen. "Just My Code" kann deaktiviert werden, indem Sie auf den Link "Show All Code" in der Übersichtsansicht klicken, aber ich würde dies hier nicht empfehlen.

Sehen Sie sich die " Funktionen, die die meisten individuellen Aufgaben erledigen" in der Zusammenfassungsansicht an. Dies zeigt Funktionen an, die die höchste Anzahl an exklusiven Stichproben aufweisen und daher auf der Grundlage des Profilierungsszenarios die teuersten aufgerufenen Funktionen sind. Sie sollten hier mehr Ihrer Funktionen (oder Funktionen, die von Ihren Funktionen aufgerufen werden) sehen. Darüber hinaus zeigt die Ansicht " Funktionen " und " Aufrufstruktur " möglicherweise weitere Details an (am oberen Rand des Berichts befindet sich ein Dropdown-Menü, um die aktuelle Ansicht auszuwählen).

Wie für Ihre Symbolwarnungen werden die meisten davon erwartet, da sie Microsoft-Module sind (System.Data.SQLite.dll nicht mit einbegriffen). Während Sie die Symbole für diese Module nicht benötigen, um Ihren Bericht richtig zu analysieren, wenn Sie "Microsoft Symbol Server" unter "Extras - Optionen - Debugging - & gt; Symbole" aktiviert und den Bericht erneut geöffnet haben, die Symbole für diese Module sollten geladen werden. Beachten Sie, dass das Öffnen des Berichts beim ersten Mal viel länger dauert, da die Symbole heruntergeladen und zwischengespeichert werden müssen.

Die andere Warnung über das Fehlschlagen der Serialisierung von Symbolen in der Berichtsdatei ist das Ergebnis, dass die Datei nicht geschrieben werden kann, weil sie von etwas anderem geöffnet wird, das das Schreiben verhindert. Die Symbolserialisierung ist eine Optimierung, mit der der Profiler bei der nächsten Analyse Symbolinformationen direkt aus der Berichtsdatei laden kann. Ohne Symbolserialisierung muss die Analyse einfach die gleiche Menge an Arbeit leisten wie beim ersten Öffnen des Berichts.

Und schließlich möchten Sie vielleicht auch Instrumentierung ausprobieren, anstatt in Ihren Profiling-Session-Einstellungen zu probieren. Die Instrumentation ändert die Module, die Sie angeben, um Daten bei jedem Funktionsaufruf zu erfassen (beachten Sie, dass dies zu einer sehr viel größeren .vsp-Datei führen kann). Die Instrumentierung ist ideal, um sich auf das Timing bestimmter Codeteile zu konzentrieren, während das Sampling ideal für die allgemeine Profilerfassung von Daten mit geringem Overhead geeignet ist.

Stört es Sie zu sehr, wenn ich ein wenig über Profiling spreche, was funktioniert und was nicht?

Lasst uns ein künstliches Programm zusammenstellen, von dem einige Aussagen eine Arbeit machen, die weg optimiert werden kann - d. h. sie sind nicht wirklich notwendig. Sie sind "Engpässe".

Die Subroutine foo führt eine CPU-gebundene Schleife aus, die eine Sekunde dauert. Außerdem nehmen wir an, dass die Subroutinen CALL und RETURN im Vergleich zu allem anderen unwichtige oder null Zeit brauchen.

Unterroutine bar ruft foo 10 mal auf, aber 9 dieser Zeiten sind unnötig, was Sie nicht im Voraus wissen und nicht sagen können, bis Ihre Aufmerksamkeit dorthin gelenkt wird.

Unterroutinen A , B , C , ..., J sind 10 Unterroutinen, die jeweils bar aufrufen.

Die oberste Routine main ruft jedes von A bis J einmal auf.

Also sieht der gesamte Aufrufbaum wie folgt aus:

Wie lange dauert es? Natürlich 100 Sekunden.

Sehen wir uns nun Profiling-Strategien an. Stapelproben (wie etwa 1000 Proben) werden in gleichmäßigen Intervallen entnommen.

1. Gibt es irgendeine Selbstzeit? Ja. foo benötigt 100% der Eigenzeit. Es ist ein echter "Hot Spot". Hilft Ihnen das, den Engpass zu finden? Nein, weil es nicht in foo ist.

2. Was ist der heiße Weg? Nun, die Stapelproben sehen so aus:

   Haupt - & gt; A - & gt; bar - & gt; foo (100 Proben oder 10%)
   Haupt - & gt; B - & gt; bar - & gt; foo (100 Proben oder 10%)
      ...
   Haupt - & gt; J - & gt; bar - & gt; foo (100 Proben oder 10%)

Es gibt 10 heiße Pfade, und keiner von ihnen sieht groß genug aus, um dich zu beschleunigen.

WENN SIE VERGESSEN MÜSSEN, UND WENN DER PROFILER ERLAUBT, könnten Sie bar zum "root" Ihres Anrufbaums machen. Dann würdest du das sehen:

Dann wüssten Sie, dass foo und bar unabhängig voneinander für 100% der Zeit verantwortlich sind und daher Orte für die Optimierung sind. Sie schauen sich foo an, aber natürlich wissen Sie, dass das Problem nicht da ist. Dann schauen Sie sich bar an und Sie sehen die 10 Aufrufe von foo , und Sie sehen, dass 9 von ihnen unnötig sind. Problem gelöst.

WENN SIE NICHT ZU VERGESSEN HÄTTEN, und stattdessen der Profiler Ihnen einfach den Prozentsatz von Proben zeigte, die jede Routine enthalten, würden Sie folgendes sehen:

Das sagt Ihnen, dass Sie main , bar und foo betrachten sollen. Sie sehen, dass main und foo unschuldig sind. Du siehst wo bar foo aufruft und du siehst das Problem, also ist es gelöst.

Es wird noch deutlicher, wenn neben den Funktionen auch die Zeilen angezeigt werden, in denen die Funktionen aufgerufen werden. Auf diese Weise können Sie das Problem finden, unabhängig davon, wie groß die Funktionen in Bezug auf den Quelltext sind.

JETZT, ändern wir foo , so dass sleep(oneSecond) statt CPU-gebunden ist. Wie ändert sich das?

Was es bedeutet, dass es immer noch 100 Sekunden nach der Wanduhr dauert, aber die CPU-Zeit ist Null. Sampling in einem reinen CPU-Sampler zeigt nothing .

Nun wird Ihnen gesagt, dass Sie die Instrumentierung ausprobieren sollten, anstatt Proben zu nehmen. Enthalten unter all den Dingen, die es dir sagt, sagt es dir auch die oben gezeigten Prozentsätze, also könntest du in diesem Fall das Problem finden, vorausgesetzt bar war nicht sehr groß. (Es mag Gründe geben, kleine Funktionen zu schreiben, aber sollte der Profiler eine davon sein?)

Eigentlich ist die Hauptsache, die mit dem Sampler nicht stimmt, dass er nicht während sleep (oder I / O oder andere Blockierungen) abtasten kann, und er zeigt Ihnen nicht die Prozentsätze der Code-Zeilen, nur Funktionsprozent.

Übrigens, 1000 Proben geben Ihnen schöne, präzise aussehende Prozente. Angenommen, Sie haben weniger Proben genommen. Wie viele müssen Sie eigentlich den Engpass finden? Nun, da der Flaschenhals in 90% der Fälle auf dem Stapel ist, wenn Sie nur 10 Proben genommen hätten, wären es etwa 9, also würden Sie es immer noch sehen. Wenn Sie sogar nur 3 Proben genommen haben, ist die Wahrscheinlichkeit, dass sie auf zwei oder mehr von ihnen erscheinen, 97,2%. **

Hohe Abtastraten werden überschätzt, wenn es darum geht, Engpässe zu finden.

Wie auch immer, deshalb verlasse ich mich auf zufälliges Pausieren .

** Wie habe ich 97,2 Prozent bekommen? Stellen Sie sich vor, Sie werfen eine Münze dreimal, eine sehr unfaire Münze, wobei "1" bedeutet, den Flaschenhals zu sehen. Es gibt 8 Möglichkeiten:

also die Wahrscheinlichkeit, es 2 oder 3 mal zu sehen, ist .081 * 3 + .729 = .972