Pirms Linq mēs parasti izmantojām šādu metodi, lai noteiktu, vai kolekcija nav tukša, t.i., kolekcija satur elementus:
Izmantojot atribūtu Garums vai Skaits, nav problēmu ar iepriekš minēto rakstīšanu.
Bet Linq laikmetā Enumerable.Count paplašinājuma metode "apvienoja" Length un Count īpašības, kā rezultātā tika izmantots šāds rakstīšanas veids, lai spriestu par neesamību:
Šī rakstīšana ir laba un darbojas labi, taču tā var izraisīt ļoti nopietnas veiktspējas problēmas.
Ņemiet vērā, ka tas ir iespējams, ne obligāti, un, ja iepriekš minētā metode tiek nodota kā masīvs<T>, saraksts vai kolekcija<T>, problēmu nebūs.
Tātad, kad kaut kas notiks greizi? Apskatīsim šādas metodes:
Kad zvana:
Izpildes ātrums būs diezgan lēns, un datoram bija nepieciešamas apmēram 70 sekundes, lai izpildītu avotu. Count() > 0。
Ja jūs to analizējat, jūs atradīsiet, ka ienesīguma atgriešanās i GetNums koda 5. rindā izpilda int. MaxValue, vai tas ir nepieciešams?
Faktiski, kamēr mēs atgriežam vienu elementu, mēs varam secināt, ka kopa nav tukša, un nav nepieciešams atgriezt visus elementus.
Tātad, kā spriest? Mēs varam izmantot Enumerable.Any paplašināšanas metodi:
Modificējiet SomeAction metodi šādi:
Zvaniet vēlreiz, un jūs atklāsiet, ka izpildes laiks ir niecīgs.
Rezumējot, Count() > 0 neizbēgami būs veiktspējas problēmas, kad tas saskarsies ar yeild atgriešanos.
|
Publicēts 12.10.2017 13:25:01
|
|
|
|
