LINQ - Cuestiones de performance - II

Bien, para terminar con esta serie de posts (2/2), partiremos de algo mencionado en la sección consideraciones del post anterior.
No es recomendable el uso de datasets. Entonces, continuemos con el trabajo!

La prueba -digamos, más- real es cuando se trabaje bajo un modelo con la siguiente combinación:

- Uso de Entidades (Clases mapeadas a las tablas de la base datos)
- Procedimientos Almacenados
- DataReaders
- Carga en Listas Genéricas de entidades

Luego de esto se revisarán los siguientes casos:
- Linq en C# - Procedure/DataReader/Lista Genérica en C#
- Linq usando Stored Procedure en C# - Procedure/DataReader/Lista Genérica en C#

Los ejemplos serán una continuación de los usados el post anterior.
Comencemos pues.

Tiempos de Respuesta:  Linq en C# - Procedure/DataReader/Lista Genérica en C# - Linq usando Stored Procedure en C#
Para continuar debemos considerar que se necesita construir un stored procedure, una clase y cargar una lista genérica por medio de un DataReader.
Parte del código utilizado es el siguiente:

up_ListarClientes

SpListaCs 

Para el caso de Linq usando Procedures el código es el siguiente:
SpLinq
En este caso, se utiliza el método ListarClientes, que es un reflejo del procedimiento usado líneas arriba, si requieren información sobre como realizar este mapeo, les recomiendo este post de ScottGu.

Con esto y verificando los tiempos de respuesta, se obtiene lo siguiente:

Usando Jet Brains para el Ejemplo Linq en C# (Del post anterior)
TiemposCS

Usando Jet Brains para el Ejemplo Stored Procedure/DataReader/Lista Genérica en C#
TiemposSpDrLgCs

Usando Jet Brains para el Ejemplo Linq usando Stored Procedures en C#
TiemposSpLinq

Como puede observarse, el caso propuesto obtiene 1,853 ms contra los 2,521 ms entregados por el modelo Linq usando C#.
Si, es cierto, utilizar Stored Procedures desde Linq toma 4,911 ms. Es incomparable, no?
Pasemos entonces a la revisión del uso de memoria.

Hablemos de memoria:  Linq en C# - Procedure/DataReader/Lista Genérica en C# - Linq usando Stored Procedure en C#
Pasemos a los resultados del CLR Profiler.

Usando CLR para ejemplo Linq (Del post anterior)
MemoriaLinq

Usando CLR para ejemplo Stored Procedure/DataReader/Lista Genérica en C#
MemoriaCSReader

Usando CLR para ejemplo Stored Procedure en Linq
MemoriaLinqSp

Luego de la respectiva inspección, puede observarse que el consumo de recursos con Linq es considerable con respecto al modelo Procedures/Reader/Listas.
Si hablamos del modelo Linq2Sql "tradicional" (usando expresiones de consulta), el uso de recursos es casi el doble.
Pero si cambiamos a la alternativa de aprovechar los Stored Procedures, el consumo se incrementa hasta casi el triple.
Esto ultimo si que es preocupante.

Comentarios y Consideraciones
- El caso propuesto fue usando Northwind,
- Debemos recordar que hay un grupo en codeplex que está buscando algo mas acorde a la realidad, indicando que no se ajusta a las necesidades de Linq (y adicionales).
- A pesar de ello, el modelo no tiene mucha ciencia en lo que respecta a lógica de negocio requerida.
- En resumen es un stored procedure que ejecuta un filtro sobre dos campos (seleccionados al azar por el desarrollador, es decir, yo).
- Sinceramente creía que el modelo que combina Linq y Stored Procedures tendría mejor performance.
- El código usado para la ejecución del procedure desde Linq puede optimizarse (noten que uso una variable tipo "var" cuando defino la variable datacontext)
- A pesar de ello, los tiempos de respuesta, no cambian mucho (dejo a su elección la verificación de este caso)
- El consumo de recursos me parece preocupante, pero lamenteblemente he notado que muchas veces esto pasa a segundo plano.
- Un ejemplo claro para mi, es el Windows Vista.
- A mi me gusta, pero cuando lo usaba desde mi PC de 1GB me sentía como en los viejos tiempos, pero no tenia intención de desinstalar el SO, menos regresar a Windows XP.
- Ahora tengo 3GB, sigo feliz con el Vista.
- Creo haberlo comentado al menos una vez, Linq me gusta mas como herramienta de consultas contra otros objetos, no como alternativa al SQL.
- A menos claro que se cambie el modelo de SQLServer (SQL 2012? como diría David)
- Alguna explicación a los tiempos de respuesta y consumo de memoria?
- Yo creo que los mapeos que utiliza Linq para realizar las ejecuciones contra la Base de Datos son de alguna manera, una evolución a lo que se tenia con el uso de los Typed DataSets, los recuerdan?
- Recuerdan entonces que habian "Duelos" (por decirlo asi), entre usarlos o no usarlos?
- Volviendo al ejemplo propuesto, la consulta usada retorna 3 registros.
- Es un ejemplo simple, lo sé.
- Pero eso no deja de hacerlo usar tantos recursos.
- Consideran que si usara mas de 100 registros, las respuestas cambiarán considerablemente?
- Lo dejo a su elección.

Antes de despedirme, solo me queda agradecer a David por la presión a escribir estos posts, sino fuera asi, todo esto hubiera quedado en las conversaciones del msn.
Pues claro, a Carlos Walzer, por sus posts reveladores (e inspiradores, claro está).

Saludos[at]Cama
Cross from here
Published 2/8/2008 2:52 por Jersson
Archivado en:
Comparte este post:

Comentarios

# re: LINQ - Cuestiones de performance - II

Saturday, August 2, 2008 6:38 PM por David Daniel Arroyo Zari "Ddaz"

Yo tambien quede muy sorprendido al ver los resultados.. ya que suponia que con SP linq iba a mejorar en performance...

Sinceramente ya ni se que decir... .. como decias  esto ya seria casi casi como volver a los viejos tiempos... bueno al menos en lo que se refiere a Linq2SQL

Salu2

Ddaz

# re: LINQ - Cuestiones de performance - II

Sunday, August 3, 2008 7:10 AM por Jersson

Hola,

bueno, que queda, no?

Seguir nomas.

Un Saludo.

# re: LINQ - Cuestiones de performance - II

Monday, August 4, 2008 5:01 PM por Jersson

Asi parece, he estado averiguando algunas maneras de mejorar la performance, de momento son recomendaciones, pero ya tiene que escribirse un poco mas de código.

Un Saludo.

# re: LINQ - Cuestiones de performance - II

Monday, August 4, 2008 5:09 PM por David Daniel Arroyo Zari "Ddaz"

pero no deja de ser interesante la propuesta de linq, aunque en linq2sql si se quedaron cortos... al menos para los fanaticos del performance... ojala y mejoren las propuestas para la siguiente version.

Salu2

Ddaz

# re: LINQ - Cuestiones de performance - II

Monday, August 4, 2008 8:24 PM por Juan Irigoyen

En cualquier caso, no niego que el performance sea importante en ciertas consultas pero creo que dejais un poco de lado la productividad, preguntaros el costo que tiene programar un store procedure o un modelo de base de datos con las caracteristicas de linq, te aseguro que yo lo se muy bien, y estoy dispuesto a reducir mi rendimiento en base a la mejora de  productividad en cuanto a desarrollo se refiere, en mi Empresa y creo que en el de otras muchas uno de los factores mas importantes es el tiempo de desarrollo, si tengo que mejorar el rendimiento en un determinado proceso siempre me queda lo posibilidad de realizar ciertas operaciones directamente aunque creo que a la hora de mejorar el rendimiento sera mucho mas efectivo tratar de optimizar las sentencias sql que utilizamos trabajando mas con los indices y utilizando buenas practicas en Sql o incluso mejorando el Hardware que utilizamos que al final puede ser menos costoso que cualquier otra cosa, aumentar simplemente la memoria Ram en un servidor de BD, puede multiplicar su rendimiento a un precio irrisorio si lo comparamos con las horas de trabajo que dedicamos a optimizar cualquier proceso.

# re: LINQ - Cuestiones de performance - II

Monday, August 4, 2008 9:03 PM por Jersson

Hola Juan

es muy cierto, usarlo o no y la productividad de la solución a seleccionarse, dependen de muchos factores.

Un Saludo.

# re: LINQ - Cuestiones de performance - II

Wednesday, August 6, 2008 11:50 AM por PabloNetrix

Juan, el problema viene cuando no puedes permitirte el "lujo" de perder rendimiento... imagina un entorno de 800 usuarios concurrentes conectados desde cualquier parte de España, y atacando tablas que a lo mejor alguna de ellas tiene varios millones de regisros y dos triggers asociados...

Además ya me ha pasado que cuando te piden "productividad" acabas sacrificando tantas cosas, que tus programas terminan por parecer BASIC de los 80, en lugar de aplicaciones bien encapsuladas y orientadas a objetos.

Y como en todo, normalmente en el punto medio está la virtud. ;-)

Saludos

# re: LINQ - Cuestiones de performance - II

Wednesday, August 6, 2008 1:48 PM por Juan Irigoyen

En todo caso, tener en cuenta que es un producto que acaba de nacer, y va a sufrir muchas mejorar a partir de ahora, pienso una de las elecciones con mas futuro, ya que resuelve muchos de los problemas que los desarrolladores estabamos demandando desde hace muchos años, ademas de simplificar el acceso a cualquier fuente de información estableciendo un estandar de acceso común a múltiples almacenes de datos(Sql, Oracle, DB2, etc) existen actualmente un monton de proveedores que ya tienen su enlace con Linq, a mi juicio me parece una arquitectura por la que merece la pena apostar, creo que sera la base de acceso a datos en los próximos años y como os decia siempre os queda la posibilidad de hacerlo directamente con aquellos servicios que merezcan la pena optimizar.

PabloNetrix no descarto que en ciertos casos haya que optimizar directamente, pero en entornos como los que hablas, las buenas practicas en la base de datos optimizando indices y realizando triggers y sp de una forma adecuada, ademas de mejorar el hardware del servidor, estoy seguro que te pueden hacer mejorar mucho mas de lo que puedas conseguir en otras capas. De todas formas he comprobado a lo largo del tiempo que muchas de las cosas que realiza Microsoft en sus desarrollos se deben a buenas practicas y patrones de diseño, no debemos olvidar que ellos son mas y creo que la mayoria mejores que todos nosotros, aplicando mejoras en la seguridad, globalización y otras que hacen que el rendimiento empeore, y claro si eliminamos muchas de estas practicas el acceso sera mas rápido, quiero decir que a la hora de optimizar hay que tener en cuenta muchos mas factores, no solamente la velocidad de respuesta, estoy seguro que en muchos casos cometemos errores en cuanto a seguridad y otros factores que no tomamos en cuenta.

Salu2.

# re: LINQ - Cuestiones de performance - II

Wednesday, August 6, 2008 6:22 PM por Jersson

Pablo, Juan:

- Mi punto de vista va de la mano con la solución que no sacrifique mas recursos de los que se tiene disponibles.

- Estoy a favor de la reusabilidad y buenas practicas, pero no del uso excesivo de las nuevas tecnologias que "prometen" mejoras a futuro. Esas cosas no puedo decirle a mis clientes

- Tampoco puedo decirles que debe comprar mas RAM, estamos volviendo al caso de ofrecer Windows Vista pero si quieres que funcione, compra mas RAM, mas disco, mas procesador (yo tenia 1GB con XP y todo bien, pero con Vista, ahora uso 2GB y en otros casos 3GB)

- Si hablamos de productividad, debemos encontrar la manera de que esta sea aprovechada por el cliente. Tenemos que recordar que para el cliente, es transparente si usamos magia o contratamos a una persona que digite todas las noches los procesos que se hicieron en el día.

- Cuando hice este post no solo se trataba de "tiempos de respuesta", sino de "uso de recursos", es preocupante, que con tan pocos registros se llegue al MB de uso en memoria.

- Y si hablamos de tiempos de respuesta, la diferencia existe, no?

- Linq no me parece malo, pero lamentablemente muchos estamos llegando a creer que es la "bala de plata", es decir que nos ayudará a matar cualquier mounstruo que venga. Yo no lo creo asi.

- Ahora, tampoco podemos decir que si estamos accediendo a base de datos, usemos Linq "dependiendo del caso y en otros el modo tradicional", eso genera a la larga, desorden en el desarrollo, pues la palabra "depende" es como dejar una pregunta abierta, en la cual surgen las subjetividades.

- Aqui un ejemplo simple, en la que muestran lo complicado que puede convertirse Linq, si es que queremos aplicarlo para todo (el post es reciente):

www.developerzen.com/.../the-dark-side-of-linq

- Como decia en este post, hay maneras de optimizar Linq2Sql, aqui un enlace que me parece interesante,

www.sidarok.com/.../10-tips-to-improve-your-linq-to-sql-application-performance.html

A la vez me da que pensar, por ejemplo, el tip #2 indica que debemos crear mas de un datacontext.

Incluso si se llega a ser extremo, se deberia crear un datacontext por objeto de base de datos.

No que era una manera de representar la base de datos?

- Bueno, tengo mas cosas que decir, solo puedo agregar que debemos encontrar la solucion que sea buena para el desarrollador, pero mejor aun, para el cliente. Al fin y al cabo, le vendemos un producto al cliente, no al desarrollador, no?

Ojo que no estoy menospreciando a nadie.

Un Saludo.

# re: LINQ - Cuestiones de performance - II

Wednesday, August 6, 2008 9:29 PM por David Daniel Arroyo Zari "Ddaz"

Si mal no recuerdo.. .cuando recien salio .Net ... Microsoft  Super Mega Recomendaba el uso de Typed Dataset.. recuerdo que hasta en los Devdays se usaba, en muchas demos, muchas empresas sacaron componentes que basicamente usan Datasets... y el tiempo ... hizo ver que usar datasets.. no es muy bueno... ( en muchos casos es contraproducente usarlos..).... mi duda es... Esto tendra el mismo final?"... espero que no...  la ideade linq me gusta..., pero Linq2Sql... no me convence... y por ejemplo EF usa tambien Linq2Sql..., espero que mejoren esto y lo vuelvan mas optimo... ya que sino... podria pasar como con los typed Dataset.

Logicamente depende de cada uno hacer el analisis FODA de su solucion y escoger el camino que mas le convenga.

Salu2

Ddaz

# re: LINQ - Cuestiones de performance - II

Thursday, August 7, 2008 11:03 AM por Juan Irigoyen

Jersson, cuando hablo de mejoras de Hardware, simplemente te digo que sera mucho mas barato comprar 8 Gygas de Ram, que dedicar 100 horas de trabajo a optimizar tu software, si bien optimizar es siempre parte del proceso de desarrollo, simplemente os quiero decir que muchas veces debemos ser prácticos, es como si hablamos de aspectos de la seguridad en aplicaciones, hasta donde queremos hacer segura una aplicación, aspectos como la optimización, la seguridad y otros no tienen limites, me canso de abrir aplicaciones hechas hace solo dos meses y siempre encuentro algo que puedo mejorar. Estoy deacuerdo en que Microsoft muchas veces diseña sin pensar en los recursos y esto nos causa constantes problemas, de hecho para mi uno de los problemas mas grandes que tengo, son los tiempos de compilación de mis aplicaciones en .net

En cualquier caso, el Entity framework esta basado en el modelo Entity Data Model que tiene mas de 30 años, y esta mas que probado, creo que estan haciendo un buen trabajo, si bien no descarto que comentan errores. Por ejemplo yo tengo muchos problemas para poder trabajar con bases de datos de mas de 1000 tablas, ya que la clase de entidades se hace muy grande y es muy dificil trabajar con el diseñador, espero que vayan resolviendo estos problemas y vayan optimizando algunas funciones de acceso a datos y objetos en memoria, aún asi, mi apuesta es clara, si ubiera tenido EDM y Linq hace un par de años estoy seguro de que me habria ahorrado muchas horas de trabajo, ademas es un producto que acaba de nacer.

Yo no creo que halla que aplicar Linq a todo, es como generics, habra que aplicarlo en aquellas zonas de la aplicación donde se adapte.

No se pueden comparar la arquitectura de los dataset a EF, ya que los modelos no tienen mucho que ver, de hecho los dataset tienen incorporados parte de la capa de negocios y datos mientras que en EF esto esta  resuelto en base al EDM.

Creo que hay que utilizar linq y ef en aquellos casos que se adapten, siempre hay la posibilidad de utilizar las otras tecnologias, por ejemplo yo he reducido el código de algunas de mis clases utilizando Linq, las pruebas de rendimiento me dicen que el programa es mucho mas lento, pero no me a importado ya que el código es mas claro y costo de escribir mucho menor, al fin y al cabo la perdida es de unos milisegundos y son funciones poco utilizadas.

Pero esta es solo mi opinion.

Salu2.

# re: LINQ - Cuestiones de performance - II

Thursday, August 7, 2008 4:33 PM por Sergio

Bueno por lo visto despues de años de novedades en ado.net y de nuevas herramientas y de la desconexion de los datasets y la maravilla del linq y demás bla bla bla, solo se puede concluir que la conexion dedicada del datareader no tiene rival en cuanto a la velocidad.

Si voy a hacer un sitio pequeño  o una aplicacion chica yo uso tableadapters que simplifican el desarrollo al extremo pero tienen un costo alto de desempeño, que al final de cuentas en una aplicacion chica de escritorio que no tiene millones de registros por manejar no importa, mas importa sacar un producto a tiempo

Pero si quiero hacer las cosas bien pensadas hay que definir un modelo de programación usando datareaders, y para no tener q escribir tanto codigo, nada cuesta hacer un pequeño generador de codigo que nos programe según nuestro modelo, yo trabajo de esta forma y ahorro un monton de tiempo ademas que como el modelo es mio y el generador tambien, cualquier variacion especial (que siempre hay) la puedo incluir en el generador

Bueno esperemos algun dia poder hallar algo q venza a los datareader en velocidad, mientras...

salu2

Sergio

# re: LINQ - Cuestiones de performance - II

Thursday, August 7, 2008 6:22 PM por Jersson

Juan, te comento que el EF no está teniendo la atencion que se esperaba, incluso ya se ha publicado un voto de no confianza hacia el modelo de trabajo.

Por parte de MS la respuesta ante todo esto, es... vamos a mejorarlo (la pregunta es, cuándo?). Nadie puede negar que es un avance dado por MS, pero aun presenta la madurez que uno esperaba.

Sergio, en parte considero que Linq o EF es bastante halagado por el concepto de entregarte las clases mapeadas al modelo de BD.

Pero es cierto, que un generador de código puede ayudarnos con eso. Hace mucho que los equipos de desarrollo se preocupan por la lógica principal, los CRUD se lo dejan a los generadores.

Recuerdo que comenté el uso de generadores como alternativa, esto en la sección consideraciones de la primera entrega (es decir el post anterior - geeks.ms/.../linq-cuestiones-de-performance.aspx)

Un Saludo.

# re: LINQ - Cuestiones de performance - II

Friday, August 8, 2008 10:21 AM por Juan Irigoyen

Jersson, en mi experiencia, despues de mas de un año de trabajo, he logrado crear un Entity Framework que es muy similiar al que presenta Microsoft, si bien ellos han logrado mejorar algunas de las cosas que yo habia desarrollado y yo he logrado optimizar mucho mas el acceso a datos, ya que lo desarrolle directamente para Sql Server utilizando generics, desarrollamos un generador de entidades, vistas, store procedures y algunas utilidades mas con Codedom. Con lo poco que conozco del EF, te aseguro que aunque tiene aspectos que mejorar va a marcar un antes y un despues en el acceso a datos, ya que crear un modelo para digamos 100 tablas es relativamente sencillo y muy rápido, ademas han resuelto algunos de los problemas que yo aun tengo de una forma magistral, en fin el tiempo dara la razón a unos u otros, no tiene mucho sentido discutirlo, pero si estoy seguro de que es un cambio radical con las arquitecturas anteriores y que tiene muy buena pinta, y suelo ser bastante crítico con la politica de Microsoft de inovar a costa de todo y no mejorar aquello que ya ha realizado, pero desgraciadamente yo he tenido que desarrollar todo un framework de acceso a datos para trabajar en entornos distribuidos y en algunos aspectos como el trabajo con procedimientos almacenados, funcionalidad interna de las entidades y otros, estamos muy lejos del modelo de Microsoft, de hecho aunque el mio se adapta y funciona perfectamente ya que esta optimizado usando datareaders y sp, hecho de menos la manera elegante de acceder a los datos de linq, que aunque me haga perder algo de tiempo y consuma mas recursos, me ahorra mucho tiempo en desarrollo. De hecho incorporare proximamente el EF en mis proyectos y voy a utilizar funcionalidad de mi modelo cuando necesite performance y las del EF cuando ese factor no sea tan importante.

# re: LINQ - Cuestiones de performance - II

Friday, August 8, 2008 5:08 PM por Jersson

Hola Juan, no he pretendido generar tanta "controversia", por asi llamarla,

respeto tu posición, y es bueno saber que hayas construido un modelo de trabajo que se amolde a tus necesidades.

De que EF generará un cambio de paradigma, es en parte cierto, pues el concepto ya existe, mas no directamente de la caja, como dicen algunos.

El problema es (y esto lo van a recordar mientras puedan, nuestros amigos de otras tecnologias), que se estan apurando demasiado en liberar la primera versión, yo considero que si lo dejaran digamos, para un tiempo un poco mas prudencial, mejores serían las respuestas, y no estoy hablando solo de tiempos, sino de funcionalidad, que estoy seguro te deben haber gustado.

Siempre he considerado que para hablar a fondo de algo, debemos conocerlo lo suficiente, en mi caso, me parece buena la idea, pero creo que debe madurar aun mas. Eso de hecho, no me quitará las ganas de revisarlo a fondo.

Como podrás notar, en los dos posts hablo particularmente de Linq, EF fue tocado en los ultimos comentarios, espero mas adelante darme un tiempo poder converas a mas detalle en un post relacionado a este nuevo Framework

Un Saludo.

# re: LINQ - Cuestiones de performance - II

Friday, August 8, 2008 9:53 PM por Juan Irigoyen

Estoy deacuerdo contigo, pero desgraciadamente los arquitectos, jefes de proyecto y muchos desarrolladores se ven abocados a trabajar con tecnologías que están en beta, antes esperábamos a la versión definitiva pero desgraciadamente ahora cuando sale la versión definitiva muchos estamos ya con la beta 1 del mismo producto en la siguiente versión. Digo desgraciadamente porque esto provoca que perdamos mucho tiempo en evaluar e implementar la funcionalidad de una aplicación con tal de "instalar nuestra aplicación con la última tecnología" y la mayoría de las veces cometemos un grave error, cada vez es mas fácil perder el tren y entramos en el juego que fabricantes como Microsoft nos venden, la verdad es que es difícil desarrollar hoy en día y conocer a fondo una tecnología, ya que participamos en todas las fases de desarrollo de software, y cada versión suple las carencias de otras, como me gustaría haber sido carpintero...

En cualquier caso pienso que es interesante conocer la opinión de otra gente que analiza otros aspectos y tiene diferentes puntos de vista. Personalmente creo que la "controversia" aporta mucho mas...

Salu2.

# re: LINQ - Cuestiones de performance - II

Friday, August 8, 2008 10:12 PM por Jersson

Hola Juan, lo que sucede es que para eso existen proyectos internos o en todo caso personal que cuenta con la experiencia necesaria, incluso en la tecnología que se encuentra en esas fases (sea Beta, o relacionadas)

Si bien es cierto hay muchos casos de exito que pueden demostrarnos que si se pueden usar las tecnologias desde su fase Beta, tambien están los casos en los que esta versión tuvo cambios que causaron problemas al desarrollo.

Es por eso que cuando trabajas con los productos que se encuentran en esta fase, en la seccion de instalación recomiendan no usarlos en entornos reales. Esto si, es una recomendacion de MS.

Es lamentable que hayan procesos de desarrollo en los que los arquitectos, desarrolladores o jefes de proyecto apunten a tal o cual tecnología, mas que todo por cuestiones personales, cuando lo que debemos recordar siempre es que somos profesionales y que deben haber otros motivos, sobre todo los que van acorde con los objetivos de la empresa, del cliente, y asi.

Un Saludo, y que sigan las controversias, no? al fin y al cabo de todo esto sale algo bueno.

Jersson