Ich würde bezüglich der allgemeinen Performanceüberlegungen noch gerne anmerken, das weder eine Listenimplementierung, noch die Frage, ob generisch oder nicht, noch die Frage, wie oft man eine Liste durchläuft, bezüglich der Performance entscheidend ist, sondern einzig und alleine bzw. vorrangig die Wahl der richtigen Datenstruktur bzw. des richtigen Algorithmus.
Es gibt kaum Anwendungen, die performancetechnisch ein Problem darstellen, wenn man die richtigen Datenstrukturen wählt). Ausnahmen sind hier z.B. Numbercruncher, wie Mandelbrot z.B. oder ähnliches. Natürlich lassen wir die Palette der Programme mal außen, vor, die eh nur Däumchen drehen, weil sie auf eine überlastete Platte oder das dämlich lahme "Breitbandnetz" warten...
In einer Liste suchen gehört mit Sicherheit nicht dazu. Wenn ich hier ein Performanceproblem sehe, dann nehme ich etwas anderes: Trivial eine sortierte Liste und suche nicht linear, sondern binär. Besser, eine Dictionary, die sucht noch nicht einmal mehr binär, sondern weiß quasi, wo was zu finden ist.
Ich will jetzt nicht auf dem guten Beispiel mit der Suche in Listen herumreiten oder die Vorschläge madig machen (die ja für alle nachvollziehbar wirklich etwas bringen), sondern eher den Blick darauf lenken, das man, bevor man sich eine neue CPU kauft, vielleicht das Geld doch eher in die Lektüre von guten Büchern über Algorithmik- und Datenstrukturen investiert. Das ist mit Sicherheit nachhaltiger.
Oder darin, wie man eine Datenbank richtig aufsetzt, die Indexe richtig setzt und Abfragen performant formuliert.
Ich habe hier Kandidaten, die ihren
SQL-Server mit 128 GB
RAM ausstatten und sich dann freuen, das ihre
Query doch tatsächlich nur noch 10 Sekunden dauert, obwohl das mit 4GB und dem Einrichten eines passenden Index auch in 0.1 Sekunden ginge.