XmlSerializer beschleunigen

Letzthin untersuchte ich das Startverhalten unserer neuen Software: Aus mir unklaren Gründen dauerte der Start des Programms deutlich länger als ich vermutet hätte. In solchen Fällen ist es immer sinnvoll, das Verhalten des Programms zu messen– und genau das habe ich also getan. Dazu verwende ich meistens den Profiler „dotTrace“ der Firma jetBrains.

DotTrace hat diverse Möglichkeiten das Laufzeitverhalten einer .NET Anwendung zu messen. Unter anderem kann man auf Funktionsebene sehen, wie viel Zeit eine einzelne Methode verbraucht hat. Da wurde ich relativ schnell fündig: Während das Programm geladen wird, werden mehrfach XmlSerializer erzeugt – und der Aufruf der Konstruktoren brauchte jeweils zwischen 300 und 600 MSecs.

Angesichts der Tatsache, dass die eigentliche Arbeit des XmlSerializers in Serialize() bzw. Deserialize() erledigt wird, erschien mir das ein bisschen sehr lange zu dauern. Stellte sich die Frage: Was passiert da eigentlich?

Praktischerweise ist diese Frage viel einfacher zu beantworten als man meinen möchte, denn um das herauszufinden braucht man nur einmal kurz Reflector anzuwerfen und kann sich dann den in C# umgesetzten MSIL Code der Xml-Assembly ansehen.

Man findet folgendes: Offenbar gibt es da nicht nur einen Cache von Assemblies, sondern auch irgendwelche „Generated“ Assemblies, die geladen werden können. Wenn das nicht klappt, dann erzeugt der XmlSerializer eine temporärer Assembly die dann zum (de)serialisieren verwendet wird. Die Überlegung dahinter ist relativ klar: Es wird davon ausgegangen, das im Zuge des deserialisierens sehr viele Objekte aus XML konvertiert werden sollen – da ist es einfach performanter, wenn man zur Laufzeit passende spezialisierte Klassen erzeugt, die die Konvertierung dann vornehmen. Und die Erzeugung dieser Klassen und deren Übersetzung in die temporäre Assembly braucht halt Zeit – Zeit, die sich dann beim Erzeugen der XmlSerializer-Instanz messbar bemerkbar macht. (Im Visual Studio kann man das übrigens sehen: Da wird dann im Ouput-Window eine Meldung angezeigt, laut der eine Assmebly mit mit "merkwürdigen" synthetisierten Namen geladen wurde.)

Doch leider – ganz so informativ wie erhofft ist der Eintrag dann nicht. Ich für meinen Teil vermute, das die echte Information beim Übersetzen verloren gegangen ist – doch eines kann man dem Eintrag auf jeden Fall entnehmen: Es gibt tatsächlich eine vordefinierte Assembly – nur kann der XmlSerializer die nicht verwenden.

Ein Blick ins Build-Verzeichnis der Anwendung klärt dann: Ja tatsächlich, es gibt eine „AssemblyName.XmlSerializers.dll“. Bleibt die Frage: Wo kommt die her, und warum funktioniert sie nicht?

Hier hilft nun ein bisschen Vorwissen: Mir war nämlich eigentlich von Anfang an klar, das diese Assembly existiert. Das Visual Studio hat nämlich in den Projekt-Settings eine Option, mit der man die Erzeugung dieser Assembly anwerfen kann. Ist diese Option eingeschaltet, dann wird nach dem übersetzen der Assembly das Tool „sgen“ angeworfen und erzeugt für die Assembly zusätzlich eine XmlSerializers-Assembly. Genau die versucht dann der XmlSerializer zu verwenden – und schafft das nicht.

Jetzt musste also ein bisschen Internet-Recherche herhalten. Die ergab dann folgendes: Die Option im VS 2005 existiert zwar, führt aber nicht ganz zu dem Ergebnis das man erwarten würde. Statt spezialisierte Varianten von XmlSerializern für alle Verwendungen innerhalb der Quell-Assembly zu bauen, werden nur solche für XmlSerializer erzeugt, die im Kontext von Web-Diensten zum Zuge kommen. Grund: Die Build-Regel mit der sgen aufgerufen wird, enthält den Kommandozeilenparamter /proxytypes – und der schränkt sgen in genau dieser Weise ein.

Man muss also das Build-System von VS so erweitern, das ein anderer Aufruf von sgen erfolgt – eben einer, der den „/proxytypes“ Parameter nicht enthält. Auch das ist aber einfacher als man meinen möchte.

Zunächst muss man dazu wissen, dass das komplette Build-System von Visual Studio im Wesentlichen auf MSBuild aufbaut – und das ist extrem flexibel. Im Fall eines CS-Projektes im Visual Studio sieht das ganze so aus: Das zum Projekt gehörende .csproj-File enthält im Kern eigentlich nur die „Projekt“-spezifischen Angaben. Hauptsächlich sind das die am Projekt beteiligten Dateien, externe Referenzen und ein paar Compiler-Optionen. Das Regelwerk das den Build-Vorgang steuert kommt aber aus statischen Dateien, die einfach in das „lokale“ Projekt inkludiert werden.

Nun kann man einfach ein eigenes „Target“ mit einer eigenen Build-Regel in das lokale Projekt aufnehmen – und beim Build-Vorgang wird dann diese Regel ausgewertet und der erwünschte Vorgang ausgeführt. Praktische Sachen, wenn man weiß, was man da eigentlich an welcher Stelle genau eintragen muss.

Mit ein wenig Hilfe von Grant war das aber auch einfach. In der Projekt-Datei findet sich (fast) am Ende das Import-Statement, mit dem die CSharp-Targets inkludiert werden: <Import Project=…>

Dahinter fügt man dann folgendes ein: