Înainte de Linq, de obicei foloseam următoarea metodă pentru a determina dacă o colecție este nevidă, adică o colecție conține elemente:
Folosind atributele Length sau Count, nu există nicio problemă cu scrierea de mai sus.
Dar în era Linq, metoda de extensie Enumerable.Count "unifica" proprietățile Length și Count, rezultând următorul mod de scriere pentru a judeca non-nulitatea:
Această scriere este bună și funcționează bine, dar poate cauza probleme foarte serioase de performanță.
Rețineți că este posibil, nu neapărat, iar dacă metoda de mai sus este introdusă ca un Array<T>, List sau Collection<T>, nu va exista nicio problemă.
Deci, când va merge ceva prost? Să analizăm următoarele metode:
Când sunt chemați:
Viteza de execuție va fi destul de lentă și a durat cam 70 de secunde ca calculatorul meu să execute sursa. Count() > 0。
Dacă îl analizezi, vei vedea că randamentul i din linia 5 al codului GetNums execută int. MaxValue, este necesar?
De fapt, atâta timp cât returnăm un element, putem concluziona că mulțimea este nevidă și nu este nevoie să returnăm toate elementele.
Deci, cum să judeci? Putem folosi metoda de extensie Enumerable.Any:
Modificați metoda SomeAction astfel:
Sună din nou și vei vedea că timpul de execuție este neglijabil.
În concluzie, Count() > 0 va avea inevitabil probleme de performanță când va întâlni revenirea de tip yeild.
|
Postat pe 12.10.2017 13:25:01
|
|
|
|
