He usado Linq contra algunos objetos de colección (Diccionario, Lista). Entonces, si quiero seleccionar elementos basados en un criterio, escribo una consulta Linq y luego enumero el objeto linq. Entonces mi pregunta es si Linq elimina el bucle de la colección principal y, como resultado, mejora el rendimiento.¿LINQ mejora el rendimiento al eliminar el bucle?
Absolutamente no. LINQ to Objects realiza bucles internamente. ¿De qué otra forma podría funcionar?
Por otro lado, LINQ es más eficiente que algunos enfoques que puede tomar, por la transmisión de los datos sólo cuando es necesario, etc.
En la tercera parte, se trata de capas extra de indirección (todo el iteradores, etc.) que tendrán algún efecto marginal en el rendimiento.
¡Ajá! Yo * sabía * que tenías tres manos. –
Entonces veo que Linq-to-Objects es ineficiente en escenarios "no inusuales". – NLV
Oh gawd ... no es esto de nuevo. @NLV, ¿cómo se cuantifica ineficiente? Dado que el tiempo del codificador cuesta mucho más que el hardware (incluso el hardware alquilado), y el ahorro de tiempo que proporciona Linq ... junto con el hecho de que generalmente alrededor del 90% del código no es crítico para el rendimiento, yo diría que no linq es ineficiente. – spender
Probbaly no. LINQ se presta a un código claro (con suerte) legible.
Debajo de las cubiertas está el bucle, a menos que la estructura de datos de respaldo admita un algoritmo de búsqueda más eficiente que el escaneo.
"a menos que la estructura de datos de respaldo admita un algoritmo de búsqueda más eficiente que el escaneo" - Esto, en general, no es verdadero, a menos que esa optimización haya sido * especialmente * incorporada en ese operador de consulta. Por ejemplo, 'Skip' no está optimizado para listas, hasta donde yo sé. Y actualmente no hay forma de que una colección "enganche" una consulta de LINQ to Objects. – Ani
como dije "a menos que ..." –
Mi punto es que la estructura de datos de respaldo podría * soportar * it, pero LINQ to Objects puede no usar este soporte. – Ani
No, de hecho, si está utilizando LINQ to SQL, el rendimiento será un poco peor porque LINQ después de todo es una capa adicional encima de la pila de ado.net.
si usa linq sobre objetos. hay optimizaciones hechas por linq, la más importante es "Rendimiento", que comienza a producir resultados de un IEnumerable a medida que se genera. que es mejor que el enfoque estándar que tiene que esperar para que la función llene y devuelva una Lista para iterar sobre ella.
LINQ to SQL: verdadero siempre que ambas consultas terminen siendo las mismas. Si está retirando todo y luego usando LINQ para objetos para filtrar, podría ser más lento. LINQ to objects: si ya tiene una lista precargada, no será más rápida. Todo depende de lo que está sucediendo detrás de escena. –
Cuando utiliza la consulta directamente, sigue recorriendo toda la colección. Simplemente no ve todo, porque la consulta solo devolverá elementos que coincidan con su filtro. El rendimiento general probablemente incluso reciba un golpe, simplemente debido a todos los iteradores anidados que están involucrados. Cuando llamó a ToList() en el resultado de su consulta, y luego usó este resultado varias veces, entonces sería mejor para el rendimiento.
LINQ no es mágico. –
Vi a alguien sacar un IEnumerable de un sombrero una vez ..... –