A Linq előtt általában a következő módszert használtuk annak meghatározására, hogy egy gyűjtemény nem üres-e, azaz tartalmaz-e elemeket:
A Length or Count attribútummal nincs probléma a fent említett írással.
De a Linq-korszakban az Enumerable.Count kiterjesztési módszer "egyesítette" a Length és Count tulajdonságokat, így a következő írásmódot alkalmazták a nem-nullitás megítélésére:
Ez az írás rendben van és jól működik, de nagyon komoly teljesítményproblémákat okozhat.
Fontos megjegyezni, hogy ez lehetséges, nem feltétlenül, és ha a fenti módszert <T>Tömbként, Listában vagy Gyűjteményként adják be<T>, akkor nem lesz probléma.
Szóval mikor fog valami rosszul sülni el? Nézzük meg a következő módszereket:
Amikor hívják:
A végrehajtási sebesség elég lassú lesz, és körülbelül 70 másodpercbe telt, mire a számítógépem végrehajtotta a forrást. Count() > 0。
Ha elemezzük, azt tapasztalod, hogy a GetNums kód 5. sorában lévő i hozamvisszacsatolás int fut. MaxValue, szükséges?
Valójában, amíg visszaadunk egy elemet, arra a következtetésre juthatunk, hogy a halmaz nem üres, és nincs szükség arra, hogy minden elemet visszaadjunk.
Szóval hogyan ítélkezzünk? Használhatjuk az Enumerable.Bármely kiterjesztési módszert:
Módosítsa a SomeAction metódust az alábbiak:
Ha újra mondod, azt fogod tapasztalni, hogy a végrehajtási idő elhanyagolhatatlan.
Összefoglalva, a Count() > 0 automatikusan teljesítményproblémákkal küzd, amikor visszatérésbe ütközik.
|
Közzétéve 2017. 10. 12. 13:25:01
|
|
|
|
