2010-03-15 19 views
115

ich den folgenden Absatz begegnet sind:Debug vs. Veröffentlichung Performance

„Debug vs. Veröffentlichung in der IDE Einstellung, wenn Sie Ihren Code in Visual Studio kompilieren macht fast keinen Unterschied zu Performance ... der generierte Code ist fast das gleiche. Der C# -Compiler führt keine Optimierung durch. Der C# -Compiler spuckt nur IL aus ... und zur Laufzeit ist es der JITer, der die gesamte Optimierung durchführt. Der JITer hat einen Debug/Release-Modus und das macht einen großen Unterschied für die Leistung. Aber das Schlüssel nicht ab, ob Sie das Debug ausführen oder Release-Konfiguration Ihres Projektes, dass die Schlüssel ab, ob ein Debugger angeschlossen ist.“

Die Quelle here ist und die Podcast ist here.

Kann mich jemand auf einen Microsoft-Artikel verweisen, der das tatsächlich belegen kann?

"C# Debug-vs-Release Performance" googeln meist gibt Ergebnisse sagen "Debug viel Leistung hat Hit", "Release optimiert" und "Verteilen Sie Debug Produktion" .

+0

mögliche Duplikate von [Leistungsunterschiede zwischen Debug- und Release-Builds] (http://StackOverflow.com/questions/4043821/Performance-Differences-Wintere-Debug-and-Release-Builds) –

+0

Mit. Net4 auf Win7-X 86 Ich habe ein Programm mit eingeschränkter CPU, das ich geschrieben habe und das fast doppelt so schnell in der Veröffentlichung läuft als debug, ohne dass/etc in der Hauptschleife aktiviert wird. – Bengie

+0

Auch wenn Sie sich Gedanken über den Speicherverbrauch machen, kann es große Unterschiede geben. Ich habe einen Fall gesehen, in dem ein Windows-Multithread-Dienst, der im Debug-Modus kompiliert wurde, 700 MB pro Thread verwendete, im Gegensatz zu 50 MB pro Thread im Release-Build. Der Debug-Build hatte bei typischen Anwendungsbedingungen schnell keinen Speicher mehr zur Verfügung. –

Antwort

87

Teilweise wahr. Im Debug-Modus gibt der Compiler Debug-Symbole für alle Variablen aus und kompiliert den Code wie er ist. Im Release-Modus sind einige Optimierungen enthalten:

  • nicht verwendeten Variablen nicht bei allen
  • einige Schleifenvariablen vom Compiler aus der Schleife genommen werden kompiliert bekommen, wenn sie nachweislich Invarianten
  • Code unter geschrieben werden #debug richtlinie ist nicht enthalten usw.

Der Rest ist bis zum JIT.

Edit: Vollständige Liste der Optimierungen here mit freundlicher Genehmigung von Eric Lippert

+10

Und vergessen Sie nicht über Debug.Asserts! Wenn sie in DEBUG Build fehlschlagen, werden sie den Thread anhalten und ein Meldungsfeld öffnen. In der Veröffentlichung werden sie überhaupt nicht kompiliert. Dies gilt für alle Methoden mit [ConditionalAttribute]. –

+13

Der C# -Compiler führt keine Tail-Call-Optimierungen durch; der Jitter tut es. Wenn Sie eine genaue Liste dessen haben möchten, was der C# -Compiler macht, wenn der Optimierungsschalter aktiviert ist, siehe http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch- do.aspx –

+0

ups. Du hast Recht, Eric. Ich werde es aus dem Post entfernen –

9

Ich kann die Leistung nicht kommentieren, aber der Ratschlag "Debug-to-Production nicht bereitstellen" gilt immer noch einfach, weil Debug-Code in großen Produkten normalerweise ziemlich viele Dinge anders macht. Zum einen sind möglicherweise Debug-Schalter aktiv und zum anderen werden wahrscheinlich zusätzliche redundante Plausibilitätsprüfungen und Debug-Ausgaben vorhanden sein, die nicht in den Produktionscode gehören.

+0

Ich stimme dir zu diesem Thema, aber das beantwortet nicht die Hauptfrage – sagie

+5

@sagie: ja, ich bin mir dessen bewusst, aber ich dachte, der Punkt war immer noch wert, zu machen. –

2

In msdn site ...

Veröffentlichung vs. Debug-Konfigurationen

Während Sie noch arbeiten an Ihrem Projekt , werden Sie in der Regel Ihre Anwendung mit der Debug Konfiguration erstellen, weil diese Konfiguration ermöglicht es Ihnen, den Wert von Variablen anzuzeigen und Ausführung im Debugger zu steuern. Sie können auch erstellen und testen Builds in der Release-Konfiguration, um sicherzustellen, dass Sie keine Fehler eingeführt haben, die nur manifestieren auf eine Art von Build oder die andere. Im .NET Framework Programmierung, solche Fehler sind sehr selten, aber sie können auftreten.

Wenn Sie bereit sind, Ihre Anwendung zu verteilen Benutzer zu beenden, erstellen Sie eine Release-Build, die viel sein wird kleiner und haben in der Regel viel bessere Leistung als die entsprechenden Debug-Konfiguration. Sie können die Build-Konfiguration im Build-Bereich des Projekt-Designers oder in der Build-Symbolleiste festlegen. Weitere Informationen finden Sie unter Erstellen von Konfigurationen.

5

Von msdn social

Es ist nicht gut dokumentiert ist, ist hier, was ich weiß. Der Compiler gibt eine Instanz des System.Diagnostics.DebuggableAttribute aus. In der Debug-Version ist die IsJitOptimizerEnabled-Eigenschaft True, in der Release-Version ist es False. Sie können in die Assembly-Manifest mit ildasm.exe

Der JIT-Compiler verwendet dieses Attribut dieses Attribut sehen Optimierungen zu deaktivieren, die machen würde Debuggen schwierig. Die , die Code um wie Schleife-Invariante hissen bewegen. In ausgewählten Fällen kann dies einen großen Unterschied in der Leistung machen. Normalerweise nicht.

Zuordnung von Breakpoints zur Ausführung Adressen ist die Aufgabe des Debuggers. Es verwendet die .pdb-Datei und die vom JIT-Compiler generierte Information, die die IL-Anweisung zum Code Adresszuordnung bereitstellt. Wenn Sie Ihren eigenen Debugger schreiben würden, würden Sie ICorDebugCode :: GetILToNativeMapping() verwenden.

Grundsätzlich Debug-Bereitstellung wird langsamer seit die JIT-Compiler-Optimierungen deaktiviert sind.

3

Was Sie lesen, ist ziemlich gültig. Release ist in der Regel schlanker aufgrund JIT-Optimierung, ohne Debug-Code (#IF DEBUG oder [Conditional ("DEBUG")]), minimale Debug-Symbol laden und oft nicht berücksichtigt wird, ist kleinere Montage, die Ladezeit zu reduzieren. Die Performance ist bei der Ausführung des Codes in VS aufgrund der umfangreicheren PDB und der geladenen Symbole deutlicher, aber wenn Sie sie unabhängig ausführen, sind die Leistungsunterschiede möglicherweise weniger offensichtlich. Bestimmte Codes werden besser als andere optimiert und verwenden dieselben Optimierungsheuristiken wie in anderen Sprachen.

Scott hat eine gute Erklärung auf Inline-Methode Optimierung here

this article sehen, dass eine kurze Erklärung geben, warum es in ASP.NET-Umgebung für Debug- und Release-Einstellung unterscheidet.

+0

Die Inline-Erklärung ist sehr gut – sagie

3

Eine Sache, die Sie beachten sollten, hinsichtlich der Leistung und ob der Debugger angeschlossen ist oder nicht, etwas, das uns überrascht hat.

Wir hatten ein Stück Code, in dem es viele enge Schleifen gab, die für das Debugging ewig zu dauern schienen, aber trotzdem ganz gut liefen.Mit anderen Worten, es gab keine Kunden oder Kunden, bei denen Probleme auftraten, aber als wir es ausprobierten, schien es wie Melasse zu laufen.

Der Schuldige war ein Debug.WriteLine in einer der engen Schleifen, die Tausende von Log-Nachrichten ausgespuckt, links von einer Debug-Sitzung vor einer Weile. Es scheint, dass, wenn der Debugger angeschlossen ist und diese Ausgabe überwacht, ein Overhead involviert ist, der das Programm verlangsamt. Für diesen bestimmten Code war es in der Größenordnung von 0,2 bis 0,3 Sekunden Laufzeit und 30 Sekunden, wenn der Debugger angeschlossen war.

Einfache Lösung, aber entfernen Sie einfach die Debug-Nachrichten, die nicht mehr benötigt wurden.

0

Das hängt zu einem großen Teil davon ab, ob Ihre App compute-bound ist, und es ist nicht immer einfach zu sagen, wie in Lasses Beispiel. Wenn ich die geringste Frage habe, was es macht, pausiere ich ein paar Mal und untersuche den Stapel. Wenn da etwas passiert, das ich nicht wirklich brauchte, dann ist es sofort zu sehen.

54

Es gibt keinen Artikel, der irgendetwas über eine Performance-Frage "beweist". Um eine Aussage über die Auswirkungen einer Veränderung auf die Leistung zu beweisen, müssen Sie beide Wege versuchen und unter realistischen, aber kontrollierten Bedingungen testen.

Sie stellen eine Frage zur Leistung, so dass Sie sich um die Leistung kümmern. Wenn Sie Wert auf Leistung legen, dann ist es das richtige, einige Leistungsziele zu setzen und dann eine Test-Suite zu schreiben, die Ihre Fortschritte in Bezug auf diese Ziele verfolgt. Sobald Sie eine solche Testsuite haben, können Sie sie dann einfach verwenden, um die Wahrheit oder Falschheit von Anweisungen wie "Der Debug-Build ist langsamer" zu testen.

Und außerdem werden Sie in der Lage sein, aussagekräftige Ergebnisse zu erhalten. "Langsamer" ist bedeutungslos, weil nicht klar ist, ob es eine Mikrosekunde langsamer oder zwanzig Minuten langsamer ist. "10% langsamer unter realistischen Bedingungen" ist sinnvoller.

Verbringen Sie die Zeit, die Sie damit verbracht hätten, diese Frage online zu untersuchen, indem Sie ein Gerät erstellen, das die Frage beantwortet. Auf diese Weise erhalten Sie weit genauere Ergebnisse. Alles, was Sie online lesen, ist nur eine Schätzung über was könnte passieren. Grund von Tatsachen, die du selbst gesammelt hast, nicht von den Vermutungen anderer Leute darüber, wie sich dein Programm verhalten könnte.

1

Ich bin kürzlich auf ein Leistungsproblem gestoßen. Die vollständige Liste der Produkte dauerte zu viel Zeit, etwa 80 Sekunden. Ich habe die DB eingestellt, die Abfragen verbessert und es gab keinen Unterschied. Ich entschied mich, ein Testprojekt zu erstellen, und ich fand heraus, dass der gleiche Prozess in 4 Sekunden ausgeführt wurde. Dann erkannte ich, dass das Projekt im Debug-Modus war und das Testprojekt sich im Release-Modus befand. Ich habe das Hauptprojekt in den Freigabemodus geschaltet und die vollständige Liste der Produkte dauerte nur 4 Sekunden, um alle Ergebnisse anzuzeigen.

Zusammenfassung: Debug-Modus ist viel langsamer als Run-Modus, da es Debugging-Informationen hält. Sie sollten immer im Relase-Modus bereitstellen. Sie können weiterhin Debugging-Informationen haben, wenn Sie .PDB-Dateien einschließen. So können Sie beispielsweise Fehler mit Zeilennummern protokollieren.

+0

Mit "Run-Modus" meinen Sie "Release"? –

+0

Ja genau. Release hat nicht den gesamten Debug-Overhead. –

Verwandte Themen