Før Linq brugte vi normalt følgende metode til at afgøre, om en samling er ikke-tom, dvs. en samling indeholder elementer:
Ved brug af attributten Length eller Count er der intet problem med ovenstående skrivning.
Men i Linq-æraen "forenede" Enumerable.Count-udvidelsesmetoden Length- og Count-egenskaberne, hvilket resulterede i følgende måde at skrive på for at bedømme ikke-nullitet:
Denne skrivning er fin og fungerer fint, men den kan forårsage meget alvorlige ydelsesproblemer.
Bemærk, at det er muligt, men ikke nødvendigvis, og hvis ovenstående metode sendes ind som et array<T>, liste eller samling<T>, vil der ikke være noget problem.
Så hvornår går noget galt? Lad os se på følgende metoder:
Når han kaldes:
Eksekveringshastigheden vil være ret langsom, og det tog omkring 70 sekunder for min computer at udføre kildekoden. Count() > 0。
Hvis du analyserer det, vil du opdage, at yield-returen i på linje 5 i GetNums-koden udfører int. MaxValue, er det nødvendigt?
Faktisk, så længe vi returnerer ét element, kan vi konkludere, at mængden er ikke-tom, og der er slet ikke behov for at returnere alle elementerne.
Så hvordan skal man vurdere? Vi kan bruge Enumerable.Any extension-metoden:
Ændr SomeAction-metoden som følger:
Ring det igen, og du vil opdage, at udførelsestiden er ubetydelig.
For at opsummere vil Count() > 0 uundgåeligt få performanceproblemer, når den støder på yeild return.
|
Opslået på 12/10/2017 13.25.01
|
|
|
|
