2009-07-25 25 views
34

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 & 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, Convert or map a class instance to a list of another one by using Lambda or LINQ y Convert or map a list of class to another list of class by using Lambda or LINQ .¿Cuál es la eficiencia y el rendimiento de LINQ y Lambda Expression en .Net?

Admito que Lambda y LINQ son mucho más simples y fáciles de leer y parecen ser muy potentes. 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 acerca de 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?

Respuesta

31

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 tecnología al alcance de la mano, LINQ puede ser abusado y mal usado por igual, y la capacidad de distinguir entre eso y el uso correcto depende solo de una cosa: conocimiento.

Así que el mejor consejo que puedo darle es ir y leer sobre cómo LINQ realmente se implementa.

Cosas que usted debe comprobar en son:

Y como siempre, cuando se trata de cuestiones de eficiencia, el único enfoque seguro es solo para 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.

2

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.

5

Para 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.

3

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 Lasse V. Karlsens consejos y anexar http://www.davesquared.net/2009/07/enumerables-linq-and-speed.html a su lista de enlaces.

6

Técnicamente, la manera más rápida es controlar todas las minucias usted mismo. Here are some performance tests. 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.

+3

Ese ejemplo realmente no es una buena prueba. En primer lugar, está comparando una sola iteración inversa + eliminar a iteración doble + creación de lista + eliminar. En segundo lugar, ¿por qué eliminar cuando puede * seleccionar los valores que desea *? Este método, usando LINQ es incluso más rápido que reverse-for + delete. En tercer lugar, no tiene en cuenta a JIT, al ejecutar mis pruebas dos veces muestra que, por segunda vez, el método LINQ es (sorprendentemente) 100 veces más rápido. Mis hallazgos: http://img188.imageshack.us/img188/4408/linq.png Donde "Silly LINQ" es su método de doble iteración + creación + eliminar. – JulianR

+1

Seguimiento: esa prueba no fue tanto una prueba de LINQ frente a "construcciones tradicionales", sino una prueba de código eficiente versus código ineficiente. Por ejemplo, el método List .RemoveAll (Predicate ) es mucho más rápido que el método de iteración inversa + eliminar, ¡y ciertamente mucho más bonito que escribir de esta manera eficiente usted mismo! Así que en segundo lugar su opinión es que no use un método basado en supuestos sobre la eficiencia que demuestren estar equivocados ("los constructos elegantes son lentos"), sino que se basan en la corrección. – JulianR

+1

Cosas interesantes y geniales. –

3

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

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

Básicamente se puede trabajar con cualquiera de las dos consultas LINQ y expresiones lambda ..

LINQ consultas

  1. Es legible consulta de alto nivel.

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

    proveedor de consultas
  3. mira en expresiones (agregados como nodos en el árbol de expresión) y produce formaron operadores de consulta SQL equalent tanto equalent consulta SQL durante tiempo de ejecución.

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

Expresiones Lambda

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

  2. Es compatible con todos los métodos LINQ, como las consultas LINQ. (¿Dónde, Seleccionar, contar, sumar, etc)

  3. una expresión formada árbol que hace estructura de lambda expresiones. Esto se hace mediante el compilador .

    proveedor de consultas
  4. mira en expresiones (árbol) y la expresión produce equalent consulta SQL durante tiempo de ejecución.

  5. Tipo de retorno: Delagate/ Expresión árbol

¿Cuál es el mejor?

Puede entender el LINQ (Consultas, Lambda) Si observa los puntos anteriores.

Ventaja de la consulta LINQ: es legible.

ventaja de Lambda

  1. Lambda tendrá una ventaja, ya que crea un delegado y mediante el uso la delagte que sólo puede pasar los paremeters de entrada y obtener el resultado para la entrada diferente parámetros. No necesita escribir consultas diferentes para diferentes criterios de también.

  2. Puede crear consultas dinámicas por usando expresiones Lambda y árboles de expresiones.

  3. Se pueden utilizar expresiones Lambda si desea pasar el resultado de declaración (s) a un método como argumento .

  4. expresiones son más cortas.

Así que la expresión Lambda es la mejor para el desarrollo de las consultas LINQ.

+13

Esta publicación no tiene sentido. Las expresiones Lambda y LINQ no son métodos alternativos de hacer lo mismo. Uno complementa al otro. Con mucho, la forma más legible de hacer LINQ es implementar los delegados de consulta en sintaxis lambda. Expresar 'ventajas de LINQ sobre lambda' no tiene sentido. Realizan tareas fundamentalmente diferentes. –

+0

esta respuesta incorrecta –

Cuestiones relacionadas