c# - tutorial - linq lambda where

¿Cuál es la eficiencia y el rendimiento de LINQ y Lambda Expression en.Net?

Question

He usado .Net 3.5 y VS 2008 durante más de un mes. Como la mayoría de los desarrolladores de .Net, he evolucionado a partir de la experiencia de años en .Net 1.0 y 2.0 y VS 2005. Recientemente, descubrí la simplicidad y el poder de LINQ y Lambda Expressions, como en mis preguntas recientes como Find an item in list by LINQ , Convertir o asignar una instancia de clase a una lista de otra mediante el uso de Lambda o LINQ , y Convertir o asignar una lista de clase a otra lista de clase mediante el uso de Lambda o LINQ .

Reconozco que Lambda y LINQ son mucho más simples y fáciles de leer y parecen ser muy poderosos. Detrás de escena, el compilador .Net debe generar muchos códigos para lograr esas funciones. Por lo tanto, estoy un poco indeciso para cambiar a la nueva sintaxis ya que ya conozco la "vieja" forma de lograr los mismos resultados.

Mi pregunta es sobre la eficiencia y el rendimiento de Lambda y LINQ. Quizás las expresiones de Lambda son en su mayoría funciones en línea, en ese caso creo que Lambda debería estar bien. ¿Qué hay de LINQ?

Limitemos la discusión a LINQ-to-Objects LINQ-to-SQL (LINQ-to-SQL). ¿Algún comentario, comparación y experiencias?

Answer 1

En algunos casos, LINQ es igual de rápido o más rápido que otros métodos, pero en otros casos puede ser más lento. Trabajamos en un proyecto que convertimos a linq y la búsqueda de datos es más rápida, pero la fusión de datos entre dos tablas es mucho más lenta. Hay un poco de sobrecarga, pero en la mayoría de los casos no veo la diferencia de velocidad teniendo mucho efecto en su programa.

Answer 2

No hay diferencia de rendimiento entre las consultas LINQ y las expresiones Lambda.

Debe comprender completamente cómo funciona la función LINQ (ambas consultas Lambda, LINQ) en .Net antes de buscar problemas de rendimiento.

Básicamente puedes trabajar con cualquiera de las consultas LINQ y expresiones Lambda.

Consultas LINQ

1. Es una consulta legible de alto nivel.

2. Se convierte en expresiones Lambda equivalentes y expresiones Lambda agregadas como nodos en un árbol de expresiones. Árbol de expresiones que hace la estructura de expresiones lambda. Esto se hace por compilador.

3. El proveedor de consultas examina las expresiones (agregadas como nodos en el árbol de expresiones) y produce operadores de consultas SQL equitativos, por lo tanto, una consulta sql equitativa formada durante el tiempo de ejecución.

4. Tipo de devolución: conjunto de resultados (IEnumerable).

Expresiones Lambda

1. Es un conjunto de expresiones / declaraciones y crea un árbol delegado / expresión. Se puede pasar a una función como argumento.

2. Admite todos los métodos LINQ, como las consultas LINQ. (Donde, Seleccionar, Cuenta, Suma, etc.)

3. Se formó un árbol de expresiones que crea la estructura de expresiones lambda. Esto se hace por compilador.

4. El proveedor de consultas examina las expresiones (árbol de expresiones) y produce una consulta SQL equitativa durante el tiempo de ejecución.

5. Tipo de Retorno: árbol de Delagate / Expression

¿Cuál es el mejor?

Puedes entender el LINQ (Consultas, Lambda) si miras los puntos anteriores.

Ventaja de la consulta LINQ: es legible.

Ventaja de Lambda

1. Lambda tendrá una ventaja ya que crea un delegado y al usar el delagte puede simplemente pasar los parámetros de entrada y obtener el resultado para los diferentes parámetros de entrada. No necesita escribir consultas diferentes para diferentes criterios también.

2. Puede crear consultas dinámicas utilizando expresiones Lambda y árboles de Expresión.

3. Puede usar expresiones Lambda si desea pasar el resultado de la (s) declaración (es) a un método como argumento.

4. las expresiones son más cortas

Entonces, la expresión Lambda es la mejor para el desarrollo sobre consultas LINQ.

Answer 3

No hay una sola respuesta que sea suficiente aquí.

LINQ tiene muchos usos y muchas implementaciones, y por lo tanto muchas implicaciones para la eficiencia de su código.

Al igual que con cada pieza de tecnología al alcance de la mano, LINQ puede y será abusado y mal utilizado por igual, y la capacidad de distinguir entre eso, y el uso adecuado, solo depende de una cosa: el conocimiento.

Entonces, el mejor consejo que puedo darte es ir y leer sobre cómo LINQ realmente se implementó.

Las cosas que debe verificar son:

• LINQ y cómo usa los métodos y métodos de extensión en los tipos de colecciones existentes
  • Cómo funciona LINQ
  • Cómo funciona LINQ internamente (Desbordamiento de pila)
  • ¿Cómo funciona la codificación con LINQ? ¿Qué pasa detrás de las escenas?
• Cómo se diferencia LINQ-to-objects y LINQ-to-SQL
  • Cuál es la diferencia entre las expresiones de consulta LINQ y los métodos de extensión (Desbordamiento de pila)
• Alternativas a la nueva sintaxis de LINQ, por ejemplo, el uso del método de extensión .Where (...) para colecciones

Y como siempre, al mirar las preguntas sobre eficiencia, el único enfoque seguro es solo medir. Cree un fragmento de código usando LINQ que haga una sola cosa, sepa, y cree una alternativa, luego mida ambas y trate de mejorar. Adivinar y asumir solo conducirá a malos resultados.

Answer 4

No optimice prematuramente. Use Linq y los nuevos métodos de extensión abundantemente si mejoran la legibilidad y perfila su aplicación posteriormente.

La mayoría de las veces la diferencia entre Linq y el uso de bucles lisos no es relevante en absoluto. La mantenibilidad mejorada de su código debería valer unos pocos ms. Linq puede ser más lento porque funciona en enumeradores que se implementan como máquinas de estado. Tan claro para (...) los bucles será más rápido.

Recomendaría seguir el consejo de Lasse V. Karlsens y adjuntar http://www.davesquared.net/2009/07/enumerables-linq-and-speed.html a su lista de enlaces.

Answer 5

Para las consultas LINQ, con la ''nueva sintaxis'', el IL (código) generado, fundamentalmente no es diferente de llamar directamente a los métodos de extensión proporcionados por Enumerable y Queryable.

Answer 6

Técnicamente, la forma más rápida es controlar todas las minucias usted mismo. Aquí hay algunas pruebas de rendimiento . Observe que la palabra clave foreach y el constructo FOREach LINQ son mucho más lentos que simplemente usar y escribir código de procedimiento.

Sin embargo, el compilador puede y será mejorado y usted siempre puede perfilar su código y optimizar cualquier área problemática. En general, se recomienda utilizar las funciones más expresivas que hacen que el código sea más fácil de leer a menos que realmente necesite los nanosegundos adicionales.