Reduziert auf ein ganz triviales Beispiel zeigt sich ein erhebliches Problem in der Art, wie .NET den Zugriff über Schnittstellen in nativen Code umsetzt – zumindest im normalen JIT Modus und in .NET 2.0 / 4.0. In einer Bibliothek befindet sich ein ganz harmlos ausschauender Code:
public static class Summer
{
public static long Sum( IEnumerable
{
if (summer == null)
return 0;
long res = 0;
using (var e = summer.GetEnumerator())
while (e.MoveNext())
res += e.Current;
return res;
}
}
Dieser Code wird von einem Testprogramm mit verschiedenen Parametern aufgerufen:
const int n = 10000000;
var all = Enumerable.Range( 0, n ).Select( i => (long) i );
var asArray = all.ToArray();
var asList = all.ToList();
var asHash = new HashSet
Dass die ermittelten Laufzeiten unterschiedlich sind (104 Millisekunden für das Feld, 123 für die Liste und 155 für den HashSet auf meinem x86 Vista) ist in Ordnung und ohne Relevanz. Was aber erst einmal extrem überrascht ist folgendes: diese Zeiten ergeben sich, wenn man im Testprogramm immer genau eine der Implementierungen verwendet. Werden alle drei hintereinander in die Methode der Bibliothek geschickt (etwa erst Feld, dann Liste, dann HashSet), so zeigt sich ein erheblicher Unterschied.
Wird das Feld als erstes verwendet, so ist die Laufzeit weiterhin 104ms. Wird allerdings eine beliebige andere Liste vorher aufgerufen, so landen wir plötzlich bei 170ms – das ist 63% mehr! Bei Liste und HashSet sind es immerhin noch 33% (123ms auf 175ms respektive 155ms auf 206ms). Wie kann so etwas sein? Es wird doch immer der selbe Code ausgeführt?
Die Antwort findet sich in diesem Quellcode von Microsoft. Im Endeffekt läuft es auf folgendes hinaus: wenn eine Methode einer Schnittstelle aufgerufen wird, so muss .NET herausfinden, welche Klassenmethode tatsächlich dazu gehört – dazu im Anhang ein kleiner Exkurs in die Legacy Welt von COM und MFC. Der JITter erzeugt nun für jede Methode jeder Schnittstelle ein spezielles Stück Code. Dieser Code ermittelt die Objektinstanz zur Klasse und darüber ein weiteres dynamisch erzeugtes Codefragment, das zur korrekten Methode in der Klasse verzweigt. Das Nachschlagen von Klasse zu letzterem Codefragment geschieht über eine Hashtable (mit 4096 Einträgen). Ist beim ersten Aufruf ein solcher Eintrag nicht vorhanden, so wird er automatisch erzeugt.
Da diese Nachschlageoperation selbst bei vorhandenem Eintrag in der Hashtable teuer ist, verwendet .NET einen kleinen Trick: der erste erzeugte Eintrag wird statisch geprüft. Ein direkter Vergleich auf die Klasse führt direkt zur Umlenkung. Daher der beobachtete Effekt, dass jeweils der erste Aufruf in Normalzeit abläuft und lediglich die Schnittstellen auf andere Klassen verzögert werden.
Leider ist das noch nicht die ganze Wahrheit, denn .NET verwendet eine Optimierung: wenn bei einem Aufruf nicht diese erste Schnittstelle verwendet wird, so wird ein Zähler verändert. Nach etwa 100 Fehlversuchen wird dann die Prüfung auf die erste Schnittstelle umgangen und direkt auf die Nachschlageoperation der Hashtabelle verwiesen. Würde man im Beispiel also etwa die Sequenz Feld, Liste, HashSet, Feld verwenden, so wäre bei der zweiten Nutzung des Feldes auch hier wieder die Verlangsamung zu beobachten. Wohlgemerkt: zwei identische Aufrufe unterscheiden sich in der Laufzeit um 63% – reproduzierbar!
Richtig kritisch würde es, wenn eine ständige Hash Kollision entstehen würde, da dann der Eintrag der Hashtabelle ständig neu ermittelt werden müßte. Bei 4096 Einträgen nicht wirklich wahrscheinlich, oder? Nun, der Effekt tritt natürlich nur in Szenarien auf, in denen die neben dem Aufruf der Schnittstellenmethoden (hier MoveNext und Current) sehr wenig anderes gemacht wird. In diesem Sinne ist das Beispiel natürlich gemein – aber sicher nicht exotisch! Ich würde sogar soweit gehen, dieses Feature als einen LINQ Killer zu bezeichnen. Gerade bei Verwendung von LINQ werden Schnittstellenmethoden in extremster Weise wiederverwendet und LINQ Operationen dadurch langsamer als nötig – vermutlich im Normalfall unmerklich. Ich habe mir jetzt nicht die Mühe gemacht alle Kommentare von Microsoft im obigen Source Code zu prüfen, aber es kann sein, dass diese Verwaltung mindestens Thread-übergreifen evtl. aber sogar für alle AppDomains in einem Prozess gemeinsam erfolgt. Hier könnte es zu unerwünschten Seiteneffekten durch völlig anderen Code kommen – etwa mehrere virtuelle Verzeichnisse in einem IIS Application Pool.
Soweit dazu
Jochen
Nun der versprochene Exkurs COM / MFC: programmiert man COM Objekte in C++ mit MFC / ATL, so können diese mehrere Schnittstellen unterstützen. Eine COM Schnittstelle wird dabei im Allgemeinen (Ausnahmen bestätigen die Regeln) als innere Klassen implementiert. Ein Aufruf auf eine Schnittstellenmethode erfolgt de facto mit einem für diese innere Klasse und damit Schnittstelle individuellen this Zeiger. Alle Schnittstellenmethoden wissen dies aber und korrigieren den Zeiger entsprechend – gemäß dem Offset der inneren Klasse in dem COM Objekt. Mit diesem veränderten this Zeiger kann dann transparent ein Aufruf einer Methode der eigentlichen Klasse erfolgen. Der Unterschied zu .NET ist allerdings, dass nun ein Zeiger auf eine Schnittstelle nicht mehr einfach mit einem Zeiger auf eine andere Klasse oder das COM Objekt verglichen werden kann (== aka ReferenceEquals) um festzustellen, dass tatsächlich mit einer identischen Objektinstanz gearbeitet wird. COM hat dazu eine einfache, aber nicht ganz billige Regel: zum Vergleich muss zwingend ein QueryInterface auf die IUnknown Schnittstelle herangezogen werden.
.NET hat das Problem anders gelöst und wohl die Prämisse gesetzt, dass der this Zeiger bei jedem Aufruf jeder Schnittstellenmethode identisch zur Objektreferenz sein muss. Die COM / MFC / ATL Codefragmente, die bei C++ der Compiler erzeugt, muss nun der JITter anlegen – mit den beschriebenen Nachteilen. Schön ist, dass man nun kein QueryInterface für ReferenceEquals / == braucht. Ich halte diesen Ansatz aber für extrem bedenklich und würde (wäre ich bei Microsoft für diesen .NET Teil zuständig, was ich glücklicherweise nicht bin) über einen BSTR artigen Ansatz nachdenken. Die Idee läßt sich wie folgt beschreiben: jede Schnittstelle zeigt auf eine eigene kleine Implementierung, bei der eine COM / MFC / ATL ähnliche Umsetzung erfolgt. Diese Umsetzung kann einmalig vom JITter für jede Schnittstelle jeder Klasse erstellt werden – wir sind dann weg von den Methodenaufrufen! Zu jeder Objektinstanz im Speicher wird vor den heutigen Objektdaten ein Zeiger auf die primäre Instanz (der Klasse) festgehalten – bei Verwendung der primären Klassenschnittstelle wäre dies dann genau der this Zeiger selbst. Ein ReferenceEquals müßte dann allerdings für beide Objekte eine zusätzlichen Speicherzugriff ausführen, bevor ein Vergleich stattfinden kann. Und jede Objektinstanz würde 4 / 8 Bytes größer. Schaue ich mir aber den heutigen Effekt und die Forcierung von LINQ an, scheint es mir durchaus wert, diese Richtung nicht von vorneherein auszuschliessen – mal unabhängig davon, dass ich natürlich nur die Spitze des Eisbergs sehe und es viele .NET Interna geben kann, die eine solche Implementierung grundsätzlich ausschließen.