Antes de Linq, solíamos usar el siguiente método para determinar si una colección no está vacía, es decir, si una colección contiene elementos:
Usando los atributos Longitud o Conteo, no hay problema con la escritura anterior.
Pero en la era de Linq, el método de extensión Enumerable.Count "unificaba" las propiedades Length y Count, lo que resultaba en la siguiente forma de escribir para juzgar la no nulidad:
Esta escritura está bien y funciona bien, pero puede causar problemas de rendimiento muy serios.
Ten en cuenta que es posible, pero no necesariamente, y si el método anterior se introduce como un Array<T>, Lista o <T>Colección, no habrá problema.
¿Cuándo saldrá algo mal? Veamos los siguientes métodos:
Cuando se llama:
La velocidad de ejecución será bastante lenta, y mi ordenador tardó unos 70 segundos en ejecutar el código. Count() > 0。
Si lo analizas, verás que el yield return i en la línea 5 del código GetNums se ejecuta int. ¿MaxValue, es necesario?
De hecho, mientras devuelvamos un elemento, podemos concluir que el conjunto no es vacío, y no es necesario devolver todos los elementos en absoluto.
¿Entonces, cómo juzgar? Podemos usar el método de extensión Enumerable.Any:
Modifica el método SomeAction de la siguiente manera:
Si vuelves a llamar, verás que el tiempo de ejecución es insignificante.
En resumen, Count() > 0 inevitablemente tendrá problemas de rendimiento cuando se encuentre con un retorno de yeild.
|
Publicado en 12/10/2017 13:25:01
|
|
|
|
