Prima di Linq, di solito utilizzavamo il seguente metodo per determinare se una collezione non è vuota, cioè se una collezione contiene elementi:
Usando l'attributo Lunghezza o Conteggio, non c'è problema con la scrittura sopra.
Ma nell'era Linq, il metodo di estensione Enumerable.Count "unificava" le proprietà Length e Count, portando al seguente modo di scrivere per giudicare la non nullità:
Questa scrittura va bene e funziona bene, ma può causare problemi molto seri alle prestazioni.
Nota che è possibile, non necessariamente, e se il metodo sopra viene passato come Array<T>, Lista o <T>Collezione, non ci saranno problemi.
Quindi, quando succederà qualcosa? Vediamo i seguenti metodi:
Quando chiamato:
La velocità di esecuzione sarà piuttosto lenta, e il mio computer ha impiegato circa 70 secondi per eseguire il sorgente. Count() > 0。
Se lo analizzi, scoprirai che il rendimento i nella riga 5 del codice GetNums esegue int. MaxValue, è necessario?
In effetti, finché restituiamo un elemento, possiamo concludere che l'insieme è non vuoto e non c'è bisogno di restituire tutti gli elementi.
Quindi, come giudicare? Possiamo usare il metodo Enumerable.Any extension:
Modifica il metodo SomeAction come segue:
Richiama e scoprirai che il tempo di esecuzione è trascurabile.
In sintesi, Count() > 0 avrà inevitabilmente problemi di prestazioni quando incontrerà un ritorno di qualità.
|
Pubblicato su 12/10/2017 13:25:01
|
|
|
|
