Ich finde mich oft in einer Situation, in der ich eine Operation für eine Reihe von Eigenschaften ausführen muss. Die Operation kann alles Mögliche sein, indem geprüft wird, ob eine bestimmte Eigenschaft mit irgendetwas in der Menge zu einer einzelnen Iteration von Aktionen übereinstimmt. Manchmal wird die Menge beim Aufruf der Funktion dynamisch erzeugt, manche werden mit einer einfachen LINQ-Anweisung erstellt, manchmal ist es eine fest codierte Menge, die immer gleich bleibt. Aber es gibt immer eine Konstante: Die Menge existiert nur für eine einzelne Operation und hat davor oder danach keine Verwendung .
Mein Problem ist, dass ich in meiner Anwendung so viele Punkte habe, wo dies notwendig ist, aber ich finde, dass ich sehr, sehr inkonsequent bin, wie ich diese Sets speichere. Einige von ihnen sind Arrays, einige sind Listen, und gerade habe ich ein paar verknüpfte Listen gefunden. Keine der Operationen, um die es mir besonders geht, muss sich um Indizes, Containergröße, Reihenfolge oder andere Funktionen kümmern, die von einem der einzelnen Containertypen vergeben werden. Ich habe die Ressourceneffizienz ausgewählt, weil es eine bessere Idee ist, als Münzen zu werfen. Ich denke, da die Array-Größe konfiguriert ist und es ein sehr elementarer Container ist, könnte das meine beste Wahl sein, aber ich denke, es ist eine bessere Idee, herum zu fragen. Alternativ, wenn es eine bessere Wahl gibt, nicht aus Ressourceneffizienz, sondern strikt als eine bessere Wahl für diese Art von Situation, wäre das auch schön.
Mit Ihrer Anerkennung, dass es mehr um Codierungskonsistenz als um Leistung oder Effizienz geht, denke ich, dass die allgemeine Praxis darin besteht, ein List<T> zu verwenden. Der tatsächliche Sicherungsspeicher ist ein Array, sodass Sie nicht wirklich viel (wenn überhaupt etwas Bemerkenswertes) an den Container-Overhead verlieren. Ohne weitere Qualifikationen bin ich mir nicht sicher, ob ich mehr bieten kann.
Natürlich, wenn Sie sich wirklich nicht für die Dinge interessieren, die Sie in Ihrer Frage aufführen, geben Sie einfach Ihre Variablen als IEnumerable<T> ein und Sie haben nur mit dem eigentlichen Container zu tun, wenn Sie ihn füllen. wo Sie konsumieren wird es völlig konsistent sein.
Es gibt zwei Grundprinzipien, die bei der Ressourceneffizienz beachtet werden müssen.
Sie haben gesagt, dass Indizes und Reihenfolge keine Rolle spielen und dass eine häufige Operation zutrifft. A Dictionary<T> (das ist eine Hashtabelle ) ist ein idealer Kandidat für diese Art von Arbeit. Nachschlagevorgänge auf den Tasten sind sehr schnell, was beim Abgleich hilfreich wäre. Der Nachteil ist, dass es etwas mehr Speicher verbraucht, als unbedingt erforderlich wäre. Der übliche Lastfaktor liegt bei 0,8, also sprechen wir nicht von einem großen Anstieg oder so.
Bei Ihren anderen Operationen können Sie feststellen, dass ein Array oder List<T> eine bessere Option ist, besonders wenn Sie keine schnellen Suchvorgänge benötigen. Solange Sie keine speziellen Funktionen (Suchen, Sortieren usw.) benötigen, ist es schwierig, die allgemeinen Ressourcenmerkmale von Array-basierten Containern zu übertreffen.
Liste ist wahrscheinlich im Allgemeinen gut. Es ist leicht zu verstehen (im programmierten Sinne) und einigermaßen effizient. Die codierten Sammlungen (z. B. Dict, SortedList) lösen eine Ausnahme aus, wenn Sie einen Eintrag mit einem doppelten Schlüssel hinzufügen. Dies ist jedoch möglicherweise kein Problem für das, woran Sie gerade arbeiten.
Nur wenn Sie feststellen, dass Sie ein Problem mit der CPU-Zeit oder dem Speicherbedarf haben, sollten Sie die "Effizienz" verbessern und erst dann feststellen, dass dies der Flaschenhals ist.
Unabhängig davon, welche Methode Sie verwenden, wird immer noch die zugrunde liegenden Objekte (Sammlung oder Iterator) erstellt und gelöscht, die schließlich zu einer Garbage Collection werden, wenn die Anwendung lange genug läuft.
Tags und Links c# performance containers