Linq: Använd aldrig Count() > 0 för att avgöra att mängden är icke-tom

Lilla avskum · Publicerad på 2017-10-12 13:25:01

Innan Linq använde vi vanligtvis följande metod för att avgöra om en samling är icke-tom, det vill säga en samling innehåller element:

Inloggningen är synlig.

Med hjälp av attributet Length eller Count är det inget problem med ovanstående text.

Men under Linq-eran "förenade" Enumerable.Count-extensionsmetoden egenskaperna Length och Count, vilket resulterade i följande sätt att skriva för att bedöma icke-nullitet:

Inloggningen är synlig.

Detta skrivande fungerar bra och fungerar, men det kan orsaka mycket allvarliga prestandaproblem.

Observera att det är möjligt, inte nödvändigtvis, och om metoden ovan skickas in som en array<T>, lista eller samling <T>kommer det inte att vara några problem.

Så när kommer något att gå fel? Låt oss titta på följande metoder:

Inloggningen är synlig.

När du ringer:

Inloggningen är synlig.

Exekveringshastigheten kommer att vara ganska långsam, och det tog ungefär 70 sekunder för min dator att köra källkoden. Count() > 0。

Om du analyserar den kommer du att se att avkastningsavkastningen i i på rad 5 i GetNums-koden exekverar int. MaxValue, är det nödvändigt?

Faktum är att så länge vi returnerar ett element kan vi dra slutsatsen att mängden är icke-tom, och det finns inget behov av att returnera alla element alls.

Så hur ska man bedöma? Vi kan använda Enumerable.Any extension method:

Modifiera SomeAction-metoden enligt följande:

Inloggningen är synlig.

Ring den igen och du kommer att upptäcka att utförandetiden är försumbar.

Sammanfattningsvis kommer Count() > 0 oundvikligen att få prestandaproblem när den stöter på yeild return.

[Källa] Linq: Använd aldrig Count() > 0 för att avgöra att mängden är icke-tom

Relaterade inlägg

Avsnitt som ses