Vor Linq verwendeten wir üblicherweise folgende Methode, um zu bestimmen, ob eine Sammlung nichtleer ist, d. h. eine Sammlung enthält Elemente:
Mit dem Attribut Length or Count gibt es kein Problem mit der obigen Schrift.
Aber in der Linq-Ära "vereinheitlichte" die Enumerable.Count-Erweiterungsmethode die Eigenschaften Length und Count, was zu folgender Schreibweise führte, um Nicht-Nullität zu beurteilen:
Dieses Schreiben ist in Ordnung und funktioniert einwandfrei, kann aber sehr ernsthafte Performance-Probleme verursachen.
Beachten Sie, dass es möglich ist, aber nicht unbedingt, und wenn die oben genannte Methode als Array<T>, Liste oder Sammlung übermittelt wird<T>, gibt es kein Problem.
Wann wird also etwas schiefgehen? Schauen wir uns die folgenden Methoden an:
Wenn er angerufen wird:
Die Ausführungsgeschwindigkeit ist ziemlich langsam, und es hat etwa 70 Sekunden gedauert, bis mein Computer die Quellcode ausgeführt hat. Count() > 0。
Wenn du es analysierst, wirst du feststellen, dass die Rendite i in Zeile 5 des GetNums-Codes int. MaxValue, ist das notwendig?
Tatsächlich können wir, solange wir ein Element zurückgeben, daraus schließen, dass die Menge nicht leer ist und es nicht notwendig ist, alle Elemente zurückzugeben.
Wie soll man also urteilen? Wir können die Enumerable.Any-Erweiterungsmethode verwenden:
Ändern Sie die SomeAction-Methode wie folgt:
Ruf es nochmal an, und du wirst feststellen, dass die Ausführungszeit vernachlässigbar ist.
Zusammenfassend wird Count() > 0 zwangsläufig Leistungsprobleme haben, wenn es auf yeild return stößt.
|
Veröffentlicht am 12.10.2017 13:25:01
|
|
|
|
