Performance Tipps für .net Anwendungen

Tipps für alle .net Anwendungen

Weniger Exception? s werfen

Das ?werfen? von Exceptions kann unter Umständen erhebliche Performance Einbusen bringen. Dies bedeutet jedoch nicht, dass sie im Quell Code keine Try ... Catch ... Finally Blöcke mehr integrieren sollen. Sie sollten lediglich die Anzahl der Exceptions die ihre Anwendung auslöst verringern. Bei Anwendungen die eine sehr hohe Performance benötigen sollten sie sich einmal im Debug Modus Zeile für Zeile ansehen was ihre Anwendung, sowie das Environment macht. Beispiel löst ein Response.Redirect Aufruf immer eine ThreadAbort Exception aus!

ForEach Iterationen
In C# gibt es nun eine ForEach Schleife die sie der ?normalen? C++ for(int i=0; i<=100; i++) vorziehen sollten. Die ForEach Schleife bietet dabei die Möglichkeit mit den verschiedensten Typen zu arbeiten(DataRow, DataColoumn, Controls). Wenn jedoch mit Strings gearbeitet wird, sollten sie eine normale for Schleife vorziehen, da es sich bei Strings um einfache Zeichen Arrays handelt, und diese einfacher von der CLR durchiteriert werden können als andere Objekte.

Komplexe String Operationen mit dem String Builder
Bei String Operationen geschieht folgendes: Die CLR macht eine Kopie des Strings und gibt diese zurück, wobei der String weiterhin von der Garbage Collection verwaltet wird. Wenn dieser String jedoch sehr häufig in ihrem Programm geändert wird, führt das zwangsläufig zu einem Performance Verlust, da die Speicherplatzreservierung Zeit und Pflege in Anspruch nimmt. Der StringBuilder ist jedoch nur EIIN Objekt das immer zur Verfügung steht und seinen Performance Vorteil ganz klar bei Stringmanipulationen in Schleifendurchläufen ausspielt.

Vorkompilieren von Windows Forms Anwendungen
Der Just In Time Compiler der CLR kompiliert Methoden bei Aufruf. Wenn in ihrer Windows Forms Anwendung viele Methoden bei Start der Anwendung, ausgeführt wird muss natürlich der Just in Time Compiler mehr Native Code erzeugen. Außerdem benutzt das Windows Forms Framework eine Menge an Betriebssystem spezifischen API Aufrufen. Wenn sie also der Meinung sind, dass ihre Anwendung zu langsam ist, können sie ein Tool des .net Frameworks benutzen: ngen.exe. Mit diesem Tool sind sie in der Lage ihre .net Assemblies und Win Forms Anwendungen vorzukompilieren. Dabei ist natürlich zu beachten, wann diese Vorkompilierung stattfindet, die beste Möglichkeit ist hier natürlich innerhalb einer Setup Routine auf dem Client Rechner das ngen Tool aufzurufen und abhängig von der CPU eine Native Code Anwendung erstellen zu lassen. Zu beachten ist dabei das der Just in Time Compiler natürlich optimierten Code für diese eine Maschine, bzw. CPU erzeugt!

ADO .NET

Immer den bestmöglichen Managed Provider wählen

Beim Datenzugriff sollten sie immer den bestmöglichen Provider für ihre Datenquelle wählen. Zum Beispiel ist System.Data.SqlClient.SqlConnection
ein für den Microsoft SQL Server optimierter ?managed provider?. Zu beachten ist das diese managed Provider intern eine andere ?Sprache? benutzt um mit der Datenquelle zu kommunizieren. TIP: Auf der MSDN Seite von Microsoft gibt es nun auch Managed Provider für ODBC und spezielle einen Managed Provider für unsere Oracle Freunde!

DataReader dem DataSet vorziehen

Wenn in ihrer Anwendung Daten visualisiert werden sollen, oder Daten ohne große Navigationsmöglichkeit benutzt werden sollen, sollte der DataReader immer dem DataSet vorgezogen werden. Das DataSet hat nun einmal einen gewissen Overhead. Der DataReader hingegen ist ein einfacher Daten Stream auf den sofort zugegriffen werden kann, wenn die Daten ihre Anwendung erreichen, wobei die Daten nicht zuerst in ein DataSet Objekt abgelegt werden müssen.

Benutzen von Stored Procedures sollte immer vorgezogen werden
Stored Procedures sind ein sehr performantes Tool für ihre Anwendung. Natürlich nur wenn sie diese benutzen. Sie sollten sich überlegen, ob nicht im nächsten Release ihrer Anwendung mehr Logik, was die Daten betrifft, in der Datenbank hinterlegen. Die Datenbank und die darin enthaltenen Stored Procedures, sind sehr performant und entlasten das Middle Tier, bzw. den Client.

Abschalten von Features die nicht benötigt werden:
- transaction entlistment
o Schalten des Enlist Attributes auf False im Connectin String bewirkt, dass das die Connection ohne eine Zuordnung im aktuellen Transaktions Context des Callers übergeben wird
- Primary Key Informationen wenn nicht benötigt
o Wenn Daten durch den DataAdapter abgeholt werden und in das DataSet ?geschubst? werden sollten sie die PrimaryKey Informationen abschalten wenn diese nicht benötigt werden. Bei einem automatischen Update mit dem Command Builder und dem Data Adapter ist dies nicht zu gebrauchen!
- Auto Generated Commandos
o Der DataAdapter ist in der Lage sogenannte Autogenerted Commands zu erzeugen. Dabei werden abhängig vom ersten Select Command MetaDaten aus der Datenquelle abgerufen und daraus Insert, Delete und Update Statements gebaut. Dabei ist zu beachten, dass sie weniger Einfluss auf die SQL Statements haben.
- Laden sie nur die Daten in ein DataSet die sie auch wirklich brauchen
o Um Speicherplatz zu sparen sollten sie bei Verwendung eines DataSet Objektes nur die Daten laden und in das DataSet füllen, die das Programm für den nächsten Arbeitsschritt benötigt. Die Daten werden vom DataSet ja im Speicher abgelegt => mehr Daten ó mehr Speicherverbrauch.

ASP .net Anwendungen

Intelligentes Cachen gibt ihrer Anwendung einen enormen Performance Schub

ASP .net kommt mit enormen Caching Funktionalitäten. Gehandelt wird das ganze über die <% OutputCache %> Direktive in der ASP UI Seite. Dabei gibt es ein paar Attribute für diese Direktive: Duration ist die Dauer in Minuten wie lange diese Seite im Output Cache auf dem Server gültig ist, VaryByParam ist die Einstellung für welche Parameter das Cachen gilt, VaryByHeader ist die Einstellung für spezielle http Header. Das ganze wird auch als Fragment Caching bezeichnet.

Session State nur dann benutzen, wenn es unbedingt nötig ist
ASP .net liefert im Gegensatz zu ASP eine neue Fülle an Session State Features. Generell gilt jedoch, dass sie Session State Handling nur dann aktivieren sollten wenn ihre Anwendung dies auch wirklich benötigt. Soll zum Beispiel eine ASP .net Seite nur Session Informationen auslesen, jedoch keinen Session Wert schreiben dürfen kann man über folgendes Attribut in der Page Direktive eine ReadOnly Zugriff auf die Session State Informationen gewähren EnableSessionState=ReadOnly.

View State nur dann benutzen, wenn es unbedingt nötig ist
Zum View State lässt sich ähnliches wie beim Session State sagen. Bei jedem RoundTrip den eine ASP .net Seite vollführt, muss der Server die Formularfelder mit den entsprechenden Session Werten, die der User zuvor eingegeben hat, vorausfüllen. Dies kostet natürlich Performance. Standardmäßig ist die ViewState Eigenschaft für jede ASP .net Seite eingeschaltet. Bei Seiten in ihrer Anwendung die dieses Feature nicht benötigen sollten sie in der Page Direktive EnableViewState = false setzen.

Vermeiden sie STA
Professionelle ASP Anwendungen verwenden meistens ein Mehr Schicht Modell, bei dem COM Komponenten die Business Layer und Data Layer bilden. COM Komponenten können entweder in Single Threaded Apartment Modus oder in Multi Threaded Apartment Modus erzeugt werden. Sollten eine bestehende ASP Anwendung nach ASP .net portieren und weiterhin die ?alten? STA Komponenten verwenden wird die Performance der neuen ASP .net Anwendung dramatisch verringert. Um STA Komponenten in einer ASP .net Anwendung verwenden zu können muss in der Page Direktive das Attribut ASPCompat auf True gesetzt werden. Davon ist jedoch abzuraten.