C # -Code sehr langsam mit angehängtem Debugger; MemoryMappedFile's Fehler?

Question

C # -Code sehr langsam mit angehängtem Debugger; MemoryMappedFile's Fehler?

9

Ich habe eine Client / Server-App. Die Serverkomponente wird ausgeführt, verwendet WCF in Remotemodus (binärer Formatierer, Sitzungsobjekte).

Wenn ich die Server-Komponente starte und den Client starte, wird die erste Aufgabe des Servers in & lt; 0,5 sec. abgeschlossen.

Wenn ich die Serverkomponente mit angehängtem VS-Debugger starte und dann den Client starte, dauert die Ausführung der Aufgabe mehr als 20 Sekunden.

Es gibt keine Codeänderungen - keine bedingten Kompilierungsänderungen. Das gleiche passiert, wenn ich die Server-Komponente kompiliert und in 32-Bit, 64-Bit, mit dem VS-Hosting-Prozess, ohne den VS-Hosting-Prozess, oder eine Kombination dieser Dinge.

Möglicherweise wichtig : Wenn ich den VS.NET Profiler (Stichprobenmodus) verwende, wird die App so schnell ausgeführt, als ob kein Debugger angehängt wäre. Also kann ich es nicht so diagnostizieren. Einfach geprüft, läuft der Instrumentierungsmodus auch schnell. Gleiches gilt für den Parallelitätsprofil-Modus, der schnell funktioniert.

Schlüsseldaten:

Die App verwendet relativ viel Multithreading (40 Threads im Standard-Thread-Pool). Das Erstellen der Threads geschieht unabhängig von der Zeit und ist kein langsamer Punkt. Es gibt viele Sperren, WaitHandle s und Monitor Muster
Die App löst überhaupt keine Ausnahmen aus.
Die App erstellt keine Konsolenausgabe.
Die App ist vollständig verwalteten Code.
Die App ordnet einige Dateien auf der Festplatte einer MemoryMappedFile zu: 1x750MB und 12x8MB und ein paar kleinere

Gemessene Leistung:

Die CPU-Nutzung ist in beiden Fällen minimal; Wenn der Debugger angeschlossen ist, befindet sich die CPU bei & lt; 1%
Der Speicherverbrauch ist in beiden Fällen minimal; vielleicht 50 oder 60 MB in beiden Fällen
Es gibt viele Seitenfehler (ref MMF), sie treten jedoch langsamer auf, wenn der Debugger angeschlossen ist
Wenn der VS-Hosting-Prozess nicht verwendet wird oder grundsätzlich der 'remote debugging monitor' ins Spiel kommt, dann verwendet das eine anständige CPU und erzeugt eine gute Anzahl von Seitenfehlern. Aber das ist nicht das einzige Mal, dass das Problem auftritt
Der Leistungsunterschied wird unabhängig davon gesehen, wie der Client ausgeführt wird. Die einzige Variable, die geändert wird, ist die Server-Komponente, die über 'Start with debugging' (Start mit Debugging) gestartet wird oder vom Explorer gestartet wird.

Meine Ideen:

WCF langsam beim Debuggen?
MemoryMappedFiles langsam beim Debuggen?
40 Threads verwendet - langsam zu debuggen? Vielleicht melden Monitore / Sperren den Debugger? Thread-Planung wird seltsam / Kontextwechsel sehr selten?
Kosmische Hintergrundstrahlung, die VS Intelligenz und grausamen Sinn für Humor verleiht

Alle scheinen dumm unwahrscheinlich.

Also, meine Fragen:

Warum passiert das?
Wenn # 1 unbekannt ist, wie kann ich diagnostizieren / herausfinden?

c# .net-4.0 debugging performance memory-mapped-files

Kieren Johnstone 19.10.2011, 20:58

quelle

2 Antworten

3

Da dies eines der ersten Ergebnisse beim googlen für dieses Thema ist, möchte ich hier meine Problemlösung hinzufügen, in der Hoffnung, jemand 2 Stunden Forschung zu sparen, wie in meinem Fall.

Mein Code wurde von 30 Sekunden ohne Debugger auf 4 Minuten mit Debugger verlangsamt. weil ich vergessen habe, einen bedingten Haltepunkt zu entfernen. Diese scheinen die Ausführung enorm zu verlangsamen, also pass auf diese auf

Tyron 25.04.2016 09:41

quelle

Tags und Links c# .net-4.0 debugging performance memory-mapped-files

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Kann ich den Log-Header für Ruby Logger deaktivieren?

score 9 · Accepted Answer

Ausnahmen können sich erheblich auf die Leistung einer Anwendung auswirken. Es gibt zwei Arten von Ausnahmen: Ausnahmen der ersten Chance (die mit einem try / catch-Block elegant behandelt wird) und nicht behandelte Ausnahmen (die die Anwendung letztendlich zum Absturz bringen).

Standardmäßig zeigt der Debugger keine Ausnahmen der ersten Chance an, sondern nur unbehandelte Ausnahmen. Außerdem werden standardmäßig nur Ausnahmen in Ihrem Code angezeigt. Auch wenn sie nicht angezeigt werden, werden sie dennoch behandelt, sodass die Leistung beeinträchtigt wird (insbesondere bei Auslastungstests oder großen Schleifenläufen).

Um die Anzeige der ersten Chance in Visual Studio zu aktivieren, klicken Sie auf "Debug | Exceptions", um das Dialogfeld "Exceptions" aufzurufen, und aktivieren Sie "Thrown" im Abschnitt "Common Language Runtime" Ausnahme, die Sie sehen möchten).

Um die Anzeige von Ausnahmen der ersten Chance zu ermöglichen, nicht nur von Ihrem Code, klicken Sie auf "Extras | Optionen | Debuggen | Allgemein" und deaktivieren Sie die Option "Nur meinen Code aktivieren".

Und für diese speziellen "forensischen Modus" -Fälle empfehle ich dringend, .NET Framework Source Stepping zu aktivieren (es erfordert "Enable Just My Code", um deaktiviert zu werden). Es ist sehr nützlich zu verstehen, was vor sich geht, manchmal ist es einfach inspirierend, den Call-Stack zu betrachten - und hilfreich, besonders im Fall von Vermischung der kosmischen Strahlung: -)

Zwei verwandte interessante Artikel: