Før Linq brukte vi vanligvis følgende metode for å avgjøre om en samling er ikke-tom, altså at en samling inneholder elementer:
Ved å bruke attributtet Length or Count er det ikke noe problem med teksten ovenfor.
Men i Linq-æraen "forente" Enumerable.Count-utvidelsesmetoden egenskapene Length og Count, noe som resulterte i følgende måte å skrive på for å vurdere ikke-nullitet:
Denne skrivingen fungerer fint og fint, men det kan føre til svært alvorlige ytelsesproblemer.
Merk at det er mulig, ikke nødvendigvis, og hvis metoden ovenfor sendes inn som et array<T>, liste eller samling<T>, vil det ikke være noe problem.
Så når skal noe gå galt? La oss se på følgende metoder:
Når du ringer:
Kjørehastigheten vil være ganske langsom, og det tok omtrent 70 sekunder for datamaskinen min å kjøre kildekoden. Count() > 0。
Hvis du analyserer den, vil du finne at avkastningsreturen i på linje 5 i GetNums-koden utfører int. MaxValue, er det nødvendig?
Faktisk, så lenge vi returnerer ett element, kan vi konkludere med at mengden er ikke-tom, og det er ikke nødvendig å returnere alle elementene i det hele tatt.
Så hvordan skal man vurdere? Vi kan bruke metoden Enumerable.Any extension:
Endre SomeAction-metoden som følger:
Ring det igjen, og du vil oppdage at gjennomføringstiden er neglisjerbar.
For å oppsummere vil Count() > 0 uunngåelig få ytelsesproblemer når den møter yeild return.
|
Publisert på 12.10.2017 13:25:01
|
|
|
|
