Zumindest bis zu einem gewissen Grad scheinen die BCL-Sammlungen die Belange des Paging zu berücksichtigen. Sie berücksichtigen auch CPU-Cache-Belange (was sich in gewisser Hinsicht überschneidet, da die Lokalität des Speichers beide beeinflussen kann, wenn auch auf unterschiedliche Weise).
Bedenken Sie, dass Queue<T> verwendet Arrays für die interne Speicherung. Bei reinem Zufallszugriff (d.h. wo es nie Kosten für Paging oder CPU-Cache-Flushing gibt) ist dies eine schlechte Wahl; die Warteschlange wird fast immer nur an einem Punkt hinzugefügt und an einem anderen entfernt werden und daher würde eine interne Implementierung als einfach verkettete Liste in fast jeder Hinsicht gewinnen (im Übrigen sollte eine verkettete Liste in dieser Hinsicht bei reinem Zufallszugriff nicht viel schlechter abschneiden als ein Array - was sie ebenfalls unterstützt). Wo die Array-basierte Implementierung besser abschneidet als eine einfach verkettete Liste, ist genau dann, wenn Paging und CPU-Cache berücksichtigt werden. MS hat sich für eine Lösung entschieden, die in der reinen Random-Access-Situation schlechter ist, aber in dem realen Fall, in dem Paging eine Rolle spielt, besser, so dass sie die Auswirkungen von Paging berücksichtigen.
Von außen ist das natürlich nicht ersichtlich - und sollte es auch nicht sein. Von außen betrachtet wollen wir etwas, das wie eine Warteschlange funktioniert; das Innere effizient zu gestalten ist ein anderes Anliegen.
Diesen Bedenken wird auch auf andere Weise Rechnung getragen. Die Art und Weise, wie die GC arbeitet, minimiert zum Beispiel den Umfang der erforderlichen Auslagerungen, da das Verschieben von Objekten nicht nur zu einer geringeren Fragmentierung, sondern auch zu weniger Seitenfehlern führt. Auch andere Sammlungen sind so implementiert, dass das Auslagern weniger häufig erforderlich ist, als es die unmittelbarste Lösung nahelegen würde.
Das sind nur ein paar Dinge, die mir bei meinen Recherchen aufgefallen sind. Ich würde gutes Geld darauf wetten, dass solche Bedenken auch an vielen anderen Stellen in der Arbeit des .NET-Teams berücksichtigt werden. Das Gleiche gilt für andere Frameworks. Bedenken Sie, dass das einzige große Leistungsproblem, das Cliff Click wiederholt in Bezug auf seine sperrfreie Java-Hashtabelle erwähnt (ich würde wirklich gerne meine C#-Implementierung überprüfen), neben dem der sperrfreien Gleichzeitigkeit (der Sinn der Übung) die Cache-Zeilen sind; und es ist auch das einzige andere Leistungsproblem, das er nicht abtut!
Bedenken Sie auch, dass die meisten Verwendungen der meisten Sammlungen ohnehin auf eine Seite passen!
Wenn Sie Ihre eigenen Sammlungen einführen oder eine Standardsammlung besonders intensiv nutzen, müssen Sie über diese Dinge nachdenken (manchmal reicht ein "Nein, kein Problem", manchmal nicht), aber das bedeutet nicht, dass sie nicht bereits in Bezug auf die BCL berücksichtigt wurden.
