Managed Code Performance und Test-Driven-Development

1. 09:00 - 10:15 Vortrag (Erster Teil)
2. 10:15 - 10:45 Pause
3. 10:45 - 12:00 Vortrag (Zweiter Teil)
4. 12:00 - 13:00 Mittagspause
5. 13:00 - 16:00 Übungen
6. 16:00 - 17:00 Offener Teil

1. Kurze Wiederholung: C# bzw. managed Code
2. Typische Performance Probleme
3. Tools zur Performanceanalyse
4. Unit Tests mit Microsoft Visual Studio
5. Test-Driven-Development
6. RESTful APIs bauen
7. REST mit WCF

• Automatische Speicherverwaltung
• GC räumt Speicher für uns auf
• Unterscheidung Heap vs. Stack
• Boxing / Unboxing
• Finalisierer über IDisposable

• C++ ähnlicher Syntax
• Konsistenz und lesbarkeit
• Generische Typen und Methoden
• Ko- und Kontravarianz
• Lambda Ausdrücke
• LINQ und Erweiterungsmethoden

• LINQ Abfragen (mindestens ~15%)
• Verwendung unnötig großer Objekte
• GC Fragmentierung
• Rekursive Funktionsaufrufe
• Unnötige Allocations

• Häufiges Boxing / Unboxing
• Strings und string Manipulationen
• Iteratoren
• Delegaten and Lambda Ausdrücke
• Kollektionen (Dictionary, etc.)
• IDisposable Objekte
• Nicht aufgeräumte Eventhandler

• Language Features steigern Produktivität
• Verbessern die Lesbarkeit
• Sorgen für bessere Wartbarkeit
• Daher ganz klar: Nein!
• Code dort optimieren wo es sinnvoll ist

• Boxing verschwendet Speicher
• Benötigt: Zusätzlicher Zeiger und Wert
• Außerdem muss der GC aufräumen
• Vorsicht gilt v.a. bei Überladungen
• Niemals object als Übergabeparameter verwenden

• Caches ohne Discard-Policy
• Referenzen auf temporäre Objekte
• Niemals async void verwenden
• Arrays eindampfen (n auf 1-dimensional)
• Permanente Objekte vor den temporären alloziieren
• Strukturen für kl. Objekte verwenden

• Klassen bei x86 mindestens 12 Bytes
• Objekte kleiner 16 Bytes sollten Strukturen sein
• Strukturen liegen am Stack und nicht am Heap
• Niemals mehr als 64 Bytes in Strukturen packen
• Beim Boxing werden Strukturen auf den Heap gelegt
• Allgemein gilt: Häufige Property Zugriffe vermeiden

• ... sind spezialisierte Char-Arrays und
• ... die Ursache der meisten Performance Probleme!
• Ein Char in C# sind 2 Bytes (UTF-16)
• Optimal: Verwenden von StringComparison.Ordinal
• Die .NET Methoden sind nicht sehr schnell
• Es kann sinnvoll sein eigene String Helfer zu schreiben
• Viele String.Concat Aufrufe sind tödlich

• Häufig kann man Objekte wiederverwenden
• Dies spart Speicher
• Sorgt für schnellere Verfügbarkeit
• Verhindert GC Fragmentierung
• Allerdings kann dies zu Wartungsproblemen führen
• Und das Recycling muss auch verwaltet werden

• Beispiel für geschicktes Recycling
• Ohne Pooling: 2-3 Concat Aufrufe sind OK
• Mit Pooling: Bereits ab 2 Verknüpfungen besser
• Am Besten [ThreadStatic] verwenden
• Dies sorgt für Thread-lokale Buffer

• Ein Tool zur Analyse von Application Performance
• CPU, Managed Memory und Blocked Time Analyse
• Verwendet ETW um Stack Dumps zu erstellen
• Dokumentation ist ins Tool eingebaut
• PerfView agiert systemweit
• Für jede Art von GC Memory sinnvoll

• Sowohl Bottom-up als auch Top-Down Approach möglich
• Der Call-tree ist gut für Top-Down
• Ansonsten das Call-by-name Tab verwenden
• Wichtig: Immer die relevanten Daten betrachten
• Und nur signifikante Daten verwenden (Metric/msec ≥ 0.5)
• Mindestens 2000 Stack Dumps geben (je mehr umso besser)

• Übersichtsseite zeigt Hot Path
• Außerdem CPU Auslastung per Chart
• Grafische Navigation häufiger Methoden
• Speicherbild nicht so detailliert wie PerfView
• Direkte Integration in die Projektverwaltung
• Anzeige im Codeeditor

• Grundgerüst identisch
• Möglichkeiten ein wenig eingeschränkt
• Dafür aber bequemer (direkt aus VS)
• Und hübscher / übersichtlicher dargestellt
• Allerdings an VS gebunden / nicht sehr flexibel

• Problem: Wie testet man Code?
• Lösung: Schreiben Code (!) zum Testen von Code (...)
• Einschränkungen: Testbarkeit, Verläßlichkeit, Abdeckung
• Nur sehr einfache (d.h. ohne Logik) Tests
• Nur Deterministische Codes können getestet werden
• z.B. keine einfachen Tests für Zufallsgeneratoren

• Gute Abdeckung (Code coverage) notwendig
• Coverage gibt relative Zahl der genommenen Pfade an
• Ein Codepfad ist ein möglicher Durchlauf der Logik
• Gibt z.B. auch an wieviel Methoden verwendet wurden
• Bevorzugt public Methoden testen
• Ruhig mehrere Testabfragen pro Testmethode
• Aber nie mehr als ein Szenario überprüfen

• Es gibt mehrere Frameworks um Unit-Tests durchzuführen
• Eins der ältesten ist NUnit
• Direkt ins Visual Studio ist MSTest integriert
• Interessant: Speicherung der Testergebnisse
• Können ins Build- oder VC-System integriert werden
• Standardmäßige / geplante Ausführung möglich
• Kein Commit ohne (neue und) erfolgreiche Tests

• Können Tests direkt im Visual Studio debuggen
• Auslagerung der Tests in eine Bibliothek
• Spezielle Attribute dekorieren die Tests
• z.B. [TestMethod] für einen Test
• Tests sind in Klassen mit [TestClass] integriert
• Es wird eine neue Instanz pro Testmethode erzeugt
• Statische Assert Klasse verwenden

• TDD soll für saubere Codeentwicklung sorgen
• Das Prinzip ist einfach aber ...
• ... anfangs problematisch umzusetzen
• Vor jeder neuen Methode soll ein Test (ent)stehen
• Neue Features können nur durch neue Tests implementiert werden
• Wichtigstes Prinzip: Red-Green-Refactor

• Nutzt das HTTP Protokoll aus
• Idee: Eine URL ist das Ergebnis einer Operation
• (CRUD) Operationen werden durch HTTP Methoden markiert
• Rückgaben (OK, Fehler, ...) über Status-Codes
• Mögliche Datenformate u.a. XML und JSON
• Ermöglicht Entwicklung standardisierter APIs
• Keine Vorschrift über die Implementierung

• Adressierbarkeit (eindeutige Adresse)
• Unterschiedliche Repräsentationen (z.B. XML, JSON)
• Zustandslosigkeit (keine dauerhafte Verbindung)
• Operationen (GET, PUT, POST, DELETE)
• Verwendung von Hypermedia (z.B. Referenzen in Daten)

• Einzige Voraussetzung: Das HTTP-Protokoll
• Einige Frameworks sind bereits gut ausgestattet
• Beispiel: ASP.NET MVC 4 mit integrierter Web API
• Ansich alles mit ASP.NET (MVC) leicht möglich
• Allerdings: MVC 4 bietet eine standardisierte Schnittstelle
• Vorteil für uns ist die ultra schnelle Entwicklung

• Die Web API ermöglicht einen zentralen Zugriff
• Die Daten werden je nach Anfrage in JSON oder XML geliefert
• Müssen nur von ApiController erben
• Die Methoden heißen dann Get, Post, ...
• Auch OData Queries sind möglich ([Queryable])
• Auch Paging kann sehr leicht integriert werden

• Nachfolger von Webservices
• Ermöglicht Service-Oriented-Architecture (SOA)
• Vereinigt .NET Remoting, Webservices, COM+, ...
• Idee: Services über sog. Contracts aufbauen
• Definition von Endpunkten, API und Protokoll
• Zentrales Konzept: Behaviors

• Müssen nur HTTP als Endpunkt-Protokoll verwenden
• Wichtig: Methoden müssen richtig deklariert sein
• Deklaration über [WebInvoke] im Contract
• Die Web.config muss entsprechend angepasst werden
• Als Endpunkt-Behavior nimmt man <webHttp /> mit

• Problem: Unterschiedliche Pfade für mehrere Formate benötigt
• Die Lösung ist elegant: eigene WebHttpBehavior Implementierung
• Müssen den Accept Header untersuchen
• Ausgabe erfolgt dann im akzeptierten Format
• Somit wird das Format über den HTTP-Header, anstelle der URL bestimmt

• Wichtig: Zum Senden das richtige Format (z.B. application/xml) einstellen
• Ansonsten keine automatische Erkennung
• Im Contract [XmlSerializerFormat] verwenden
• Ebenfalls Sinnvoll: BodyStyle = WebMessageBodyStyle.Bare
• Zugriff auf Ausgabe über WebOperationContext.Current
• z.B. StatusCode setzen in OutgoingResponse.StatusCode

Florian Rappl, Universität Regensburg

• Web: www.florian-rappl.de
• Mail: mail@florian-rappl.de
• Google+: gplus.to/FlorianRappl

• Beispiele: github.com/FlorianRappl/PerformanceTDD
• Präsentation: talks.florian-rappl.de/PerformanceTDD