Ennen Linqia käytimme yleensä seuraavaa menetelmää selvittääksemme, onko kokoelma ei-tyhjä, eli sisältää alkioita:
Length- tai Count-attribuutilla yllä olevassa kirjoituksessa ei ole ongelmaa.
Mutta Linqin aikakaudella Enumerable.Count-laajennusmenetelmä "yhdisti" Length- ja Count-ominaisuudet, mikä johti seuraavaan kirjoitustapaan ei-nollan arvioinnissa:
Tämä kirjoitus toimii hyvin ja toimii, mutta se voi aiheuttaa vakavia suorituskykyongelmia.
Huomaa, että se on mahdollista, ei välttämättä, ja jos yllä oleva menetelmä välitetään <T>taulukkona, listana tai <T>kokoelmana, ongelmaa ei ole.
Milloin jokin menee pieleen? Katsotaanpa seuraavia menetelmiä:
Kun kutsutaan:
Suoritusnopeus on melko hidas, ja tietokoneeni käynnistyi noin 70 sekunnissa lähteen suorittamiseen. Count() > 0。
Jos analysoit sitä, huomaat, että yield return i GetNums-koodin rivillä 5 suorittaa int. MaxValue, onko se välttämätöntä?
Itse asiassa, kunhan palautamme yhden alkion, voimme päätellä, että joukko on ei-tyhjä, eikä kaikkia alkioita tarvitse palauttaa lainkaan.
Miten siis arvioida? Voimme käyttää Enumerable.Any -laajennusmenetelmää:
Muokkaa SomeAction-menetelmää seuraavasti:
Kutsu se uudestaan ja huomaat, että teloitusaika on mitätön.
Yhteenvetona, Count() > 0 kohtaa väistämättä suorituskykyongelmia, kun se kohtaa paluun.
|
Julkaistu 12.10.2017 13.25.01
|
|
|
|
