LINQ – Cuestiones de performance

Bien, sinceramente quisiera comentarles todo lo que he podido averiguar, investigar, estudiar y conversar al respecto.
La verdad es que el post sería interminable y como le decia a David, pues, no tendría mucho sentido (explicaciones sobran)

De LINQ puedo decirles que hace tiempo que nos enteramos de su advenimiento, yo por mi parte, estaba emocionado, recuerdo que alguna vez dije frameworks sobre frameworks, y lo mejor, frameworks y mas frameworks!

Es que, al fin y al cabo, todo lo que competa a Framework 3.0 / 3.5 y relacionados, significa para mi frameworks sobre frameworks.
Siendo la base, pues nuestro querido .net framework (2.0, por supuesto).

Es cierto, Linq2Sql es muy interesante, que uno no necesite conocer T-SQL para trabajar y realizar ejecuciones contra la base de datos, puede ser para muchos, un gran alivio.

No para mi.

Considero que si somos algo puristas al respecto, uno debe realizar una tarea con la mejor herramienta disponible, a su vez, debe contarse con el experto en el ambito.
No recuerdo cuando fue la ultima vez que estuve en un proyecto en el que no habia DBA, la verdad no recuerdo, quizá fue en la universidad, pero hace mucho tiempo que ademas de un DBA, el personal de desarrollo tiene la capacidad necesaría para construir un stored procedure con menor probabilidad de ajuste en lo que respecta a lógica y performance.

Por ese aspecto no me preocuparía mucho tener como alternativa, el uso de Linq2Sql.

Pero dejemos mi punto de vista de lado, comencemos con una de mis preocupaciones.
Creo yo, con el tiempo he mencionado algunas de ellas, pero una vez no está de mas.

Estaba algo interesado en la forma de trabajo de LINQ, pues es interesante todo esto de los datacontext y expresiones de consulta dentro del código .net, pero queria ver exactamente como hacía para obtener la información de la base de datos.

Encontré la respuesta con un poco de código a la mano y una que otra depuración cuando llegaba a la expresion de consulta.
Ahora es menos complicado encontrarnos con imagenes como la siguiente (via lancefisher.net):
 

Como puede notarse, la expresión se transformará en T-SQL.

Todos felices, no? el CLR se encarga de interpretar parte de lo que escribimos, transformándolo en una consulta SQL que será enviada a ejecutarse contra la base de datos.

Dije, interpretar. Es decir, estariamos regresando, en parte al código interpretado.

Por otro lado, el T-SQL generado será enviado desde nuestra aplicación hacia la base de datos, cierto?
Si lo tomamos desde otro punto de vista, estamos regresando al concepto de escribir las sentencias SQL dentro de la aplicación.
Estariamos obviando entonces el uso de stored procedures?
Claro, este es un tema controversial, como puede notarse aquí, aquí, aquí o aquí.
Por mi parte soy partidario del uso de stored procedures.

Cuando hablamos de performance uno recuerda al instante “tiempo de respuesta al cliente”, lo cual es cierto, pero que pasa si hablamos de espacios de memoria? y qué hacemos con la memoria disponible?
Claro, a estas alturas uno puede olvidar esos “aspectos mínimos”, aqui me estoy refiriendo al hardware.
Lamentablemente ya se han obviado las epocas en las que se luchaba por cada bit a usarse, quizá ese sea el problema.

Pero si, “esas cosas” influyen y bastante, solo para darnos una idea, veremos algunos escenarios. Para esto usaremos Northwind.

Tiempos de respuesta: Linq en C# – Linq en VB
Lo que se hizo fue construir una expresion que contiene un filtro simple, no mostraré la imagen depurando la aplicación. Pero puedo adelantarles que la expresión SQL de la imagen anterior solo puede reproducirse cuando se trabaja en una aplicación basada en C#.

Aquí la consulta construida.

Expresiones 

Para seguir con el ejemplo usaremos las herramientas recomendadas por Carlos Walzer (esto en su sección Anti Prácticas.NET, la cual es una lectura que no deben dejar pasar), en este caso usaremos Jet Brains luego el CLR Profiler.

Usando JetBrains para el Ejemplo en VB
TiemposVB

Usando JetBrains para el Ejemplo en CS
TiemposCS 

La linea resaltada indica el tiempo de respuesta para la ejecucion del ejemplo mostrado.
La diferencia es notoria, no? bueno, algo tendrán que ver los chicos de C# no? (es que, Linq fue creado sobre C#)

Para el siguiente caso se trabajará sobre el ejemplo en C#.


Tiempos de respuesta: Linq en C# – Ejecución de T-SQL desde código C#

Se agregó el siguiente código de prueba.

SqlEnCodigo

En este caso no se está usando una librería en particular, bueno, continuemos con las pruebas de tiempos de respuesta.
TiemposCsSql

Como puede observarse, ejecutar el código mostrado, demora 2688 ms, el cual, comparado con los 2521 ms del caso Linq en C#, nos indica que usar Linq en C# es mas rápido.

Debemos confiar en este resultado?
Estamos hablando de poco mas de 100 milisegundos.
Por esta diferencia debemos cambiar de forma de trabajo?
Pues bien, que ganamos? Un modelo completamente tipado (recordemos que las primeras propuestas venian de la mano con los datasets tipados).
Esa es una buena respuesta, pero aun no me siento convencido.


Hablemos de memoria: Linq en C# – Ejecución de T-SQL desde código C#
Aquí usaremos el CLR Profiler, la verdad es que me gusta bastante esta herramienta, sirve para darnos una vista diferente cuando hablamos de performance.

Usando CLR para ejemplo Linq
MemoriaLinq

Usando CLR para ejemplo C#
MemoriaCs

Aqui el asunto es algo preocupante.
Como puede observarse, el uso de memoria nos muestra un 607kB de Linq contra 187kB de C# tradicional, es decir estamos hablando de mas de 100% de diferencia en lo que respecta a consumo de recursos.
Qué deberiamos hacer al respecto? Qué modelo deberiamos seguir?
Yo aun no me siento convencido.

Consideraciones
– En primer lugar, el ejemplo usando DataSet es algo que no debería ocurrir en el mundo real, a pesar de que he visto lugares en los que se han construido asi, y que, funcionan!, asi que, por qué cambiarlo? Es lo que dirian, estoy seguro que si. Recuerdan el post del paradigma?
– Como les iba diciendo, el ejemplo fue con un DataSet, y hablando seriamente, la diferencia se volvería abismal si es que realizamos el ciclo completo usando un DataReader. Aqui aplicaremos la lógica y los mitos cazados por Carlos Walzer en su seccion Antiprácticas .Net. (Oye Carlos, no me conoces, pero ya te estoy haciendo bastante propaganda!!!!, es broma, es broma)
– Debemos tomar en cuenta que dejé el ejemplo con la sentencia SQL incrustada en el código C#, la respuesta mejorará si es que hablamos de una llamada a un stored procedure.
– Aplicando lo aprendido por los posts de Carlos, comprenderemos a detalle que el DataReader combinado con modelos de entidades y listas genéricas, es de momento, la mejor alternativa en lo que respecta al trabajo y desarrollo orientados al modelo de base de datos.
– El modelo tipado ofrecido por Linq (Aqui me refiero a los datacontext y entidades análogas a las tablas de la BD) puede ser reemplazado por herramientas que generan entidadas mapeadas a las tablas (Aqui me estoy refiriendo a generadores de código, en el mercado hay cientos, y que no decir en cada empresa de desarrollo)
– Este post no busca controversia alguna, hace mucho que conocí una frase que nos saca de algunas situaciones y esta es “eso depende” (y esto a veces genera desorden)
– Personalmente hablando, considero Linq como un lenguaje interesante, pero que debe afinarse en muchas cosas.
– Lo bueno de todo esto es que uno puede seguir construyendo sus procedimientos SQL y enlazarlos a las clases Linq2Sql, pero eso es mas trabajo, no? (Qué creian que el designer nos iba a ayudar toda la vida?)
– Me despido

Saludos[at]Cama
Cross from here

Para qué debe usarse la depuración? (y cuándo?)

Depurar el código tal vez no sea la respuesta indicada si es que se necesita entender el proceso de un negocio en particular.

Menos aun si es que si quiere identificar de buenas a primeras un problema.

Menos aun si es que estamos hablando de la depuración línea por línea.

No estoy en contra de la depuración, no he dicho eso.
Con lo que no estoy de acuerdo es con el uso incorrecto que se le dá, a veces pienso que el termino apropiado es “abusar” de tal funcionalidad.

Considero que si tenemos que depurar una aplicación es debido a un funcionamiento no esperado de la misma, algo que el código no tenia contemplado, si… una excepción a la regla.

Correcto, una parte de la depuración debe ser cubierta por el manejador de excepciones,
Pues claro, dado a que, si sucede un problema en el código, uno no debería preguntarse dónde comenzar, menos aun basarse en corazonadas del tipo “a ver, en que ventana se cae?“. (A menos claro, que uno termina cayendo por las corazonadas, observaciones y/o experiencias)

Si es que estamos en una construcción debemos tener en cuenta que el mensaje de error nos tiene que entregar información suficiente que sirva como base para identificar el problema.

En este caso la corazonada se convierte en pregunta del tipo “veamos el mensaje de error
Es muy cierto que con el tiempo una persona termina preguntando “qué dice el mensaje de error?” (incluso por teléfono), pero la idea es que la descripción entregada por la misma sea comprensible por personas de menor experiencia.

Cómo se logra esto? si estamos en etapa de construcción, el detalle debe ser explícito, incluyendo información del stack (okey, creo que fui demasiado técnico), es decir hay maneras de obtener incluso la línea de código que presenta el problema.

Con esto ya sabriamos donde comenzar y el espectro de revisión será cada vez menor.
Y eso que no estamos mencionando aspectos muy importantes como lo son, las pruebas unitarias.

Cuando el rango de revisión es cada vez mas pequeño, estamos obligados de manera inconsciente, a reemplazar la depuracion línea por línea por una revisión del código manteniento un correcto uso de los puntos de interrupción (es decir, por ejemplo, antes y despues de la llamada a una función).

Claro, que esto puede lograrse mientras mas información del error se tenga. Y si estamos hablando de construcciones propias, pues podemos controlarlo, o no?

Ahora, si estamos hablando de algun legado que tenemos que terminar de construir o agregar funcionalidad y este sistema no cuenta con un manejador de excepciones o tiene mensajes no apropiados al ojo humano (es decir, error general, por favor, arreglame), pues preparense, que necesitan paciencia.

Saludos[at]Trabajo
Cross from here

Delegados – Punteros a Funcion? si… pero qué mas?

No pretendo ser largo en este post, acabo de recibir una alerta que explica de manera muy didáctica el uso de los Delegados.
Como diría un amigo “si con eso ya no entiendes, pues, preocupate”

Aquí la dirección:http://dotnetslackers.com/articles/net/Delegates-in-NET.aspx
Como podrán observar el post fue publicado hace poco, la verdad vale la pena.

Que contiene el post?
pues un detalle de los delegados simples, los compuestos (si, compuestos o multicast) y su relación con los eventos.

Las fuentes de ejemplo, ordenadas, detalladas.
Qué mas puedes pedir? (Por favor, no me pidan que traduzca)

Saludos[at]Cama
Cross from here

Recomendamos que uses la versión "Beta"

Buena frase, pero que tanto podemos acercarnos a esta realidad?

Via el (nuevo) blog de Grant Holliday (nuevo refuerzo de los chicos de MS) me encuentro con un post acerca de migración de VSS al controlador de fuentes ofrecido por TFS.
Terminando el post se referencia un comentario sacado de un
foro msdn, en el cual se recomienda la instalación del VS2008 SP1 Beta, para poder aprovechar algunas características muy interesantes (en realidad decía “vastly improved”).
Esto no es muy preocupante que digamos, todos hemos usado al menos una versión Beta, inclusive CTPs o versiones Alpha,

Pero, cuando realizamos la instalación, todo esto lo hacemos bajo nuestra responsabilidad, incluso los chicos de MS tienen una advertencia, “esto puede cambiar, o puede generar problemas, no lo uses en tus ambientes de producción”

Claro que algunos hemos cometido una que otra imprudencia, pero al menos de mi parte o de los equipos en los que estuve, manejamos el concepto de analizar primero lo que vamos a instalar, revisando posibles riesgos y de acuerdo a ello, pues instalamos.
Puede sonar algo burocrático pero existe un concepto que el buen
ScottHa mencionó hace poco, el del CYA, es decir “Cover Your Ass“.

En fin, lo que me sorprende es que en el post, la persona en mención (que dicho sea de paso, trabaja en MS) recomiende abiertamente usar la versión beta para resolver un problema que podemos catalogarlo como parte de lo que llamamos comunmente del “día a día”. Pues, estamos hablando del código fuente!

Claro que, de seguir la recomendación, en el proceso de instalación, MS nos dirá “cuidado, esto es un Beta”. Algo contradictorio, no?

Es nuestra responsabilidad, claro pero:
– Debemos considerar tambien la importancia de la información con la que estamos lidiando, esto debería primar en la decisión de usar o no una tecnología que aun no termina de construirse o que no es aun, libre de fallas.
– Al menos tengamos en cuenta los posibles riesgos y la incertidumbre de los mismos.
– De estos riesgos, considerar seriamente como es que van los cambios de especificación entre versión y versión. Para esto no es necesario que hagamos ese trabajo, hay blogs dedicados a mostrarnos como cambió el CTP de Abril con respecto al de Marzo (y asi hasta el final de los tiempo). Cuestion de preguntarle a google!.
O bueno, si queremos mas pruebas, podemos
usar herramientas que hacen comparaciones en diversos niveles para mostrarnos la tasa de cambios.

Sin mas me despido,
Saludos[at]Casa
Cross from
here

Lo que busco en "la documentación" de una librería

Acabo de descargar la documentación de una libreria de acceso a datos.
Ustedes dirán, “recien documentandose sobre librerias de acceso a datos?”, pues bien, comentemos sobre esto.

Lo gracioso es que, me enviaron un enlace donde mencionaban una nueva librería, y bueno, la propaganda llamaba la atención, pues mejorar la productividad o usabilidad sin necesidad de experticia en SQL, como que te hace pensar un poco, no?

Asi que fuí a la página, busqué información a mayor detalle, nada.
Encontré la seccion documentación, descargue 5 MB en formato chm.

Fiasco.
Total.

Sin animo de ofender a nadie ni considerarme mas de lo que pocos puedan calificarme, considero que “documentación” no tiene que ver solamente con la especificacion de las APIs con la que deberíamos trabajar.

Me explico, “documentación” no se trata de tipos de dato de las funciones y parámetros involucrados.
Considero que si hablamos de documentación, el objetivo de la misma, es hacerse autosostenible, es decir, que no se requiera de alguien mas para comprender la usabilidad del mismo.
Es por ello que en la mayoria de casos no solo se habla de tipos de dato de funciones, sino que ademas, se maneja la descripción de la arquitectura base de las librerias, ejemplos e incluso código fuente (aunque muchos consideren esto, mucho pedir).

Existen situaciones extremas en las que además de la documentación, se entrega el código fuente de las librerias mismas. Pero esto ya es para cuestiones “académicas”. Aunque, como muchos de mis amigos dicen, “mas vale que sobre a que falte”.

La librería y documentación que originó este breve comentario, ya no viene al caso. Pero si es que llegamos a encontrarnos en el caso de construir una librería de uso comun, y con esto me refiero a mas de una persona.
Pues tengamos en cuenta que lo mejor sería que:
– La librería debería sostenerse por si sola, comentando el propósito de los métodos y sus parámetros, el riesgo a posibles confusiones, disminuye.
– El documento debería contener descripción técnica mas detallada de los componentes a usarse. Un ejemplo claro de todo esto es la manera de documentar la jerarquía DataSet-DataTable-DataColumn-DataRow.
– El documento debería contener ejemplos de uso de los métodos.
– Si es que hubieran proyectos ejemplo, con código fuente documentado, menos interrogantes quedarían.

Krysztof Cwalina posteó hace unos meses sobre algunos lineamientos que deberían tomarse en cuenta. Aqui el post y el documento adjunto, el cual es un minibreve resumen del excelente libro que publicó hace un par de años.

Bueno, de momento solo queda dejar abierto el post a todas las recomendaciones que usted, amigo lector, considere conveniente.

Saludos[at]Casa
Cross from here

La Caja – Artículos Recomendados – YSlow – Enterprise Architecture Guide

Holas, regresamos con la caja.
Artículos Recomendados
Vía Google Alerts encuentro un post que me parece muy valioso, bajo el titulo de “ASP.NET Performance Tips”, Haroon Waheed nos muestra unos tips que podrían (en si, lo hacen) mejorar la performance de nuestra aplicación web. El artículo en mención nos muestra ademas de algunos enlaces msdn, comentarios sobre cada punto que debemos considerar si es que queremos eliminar riesgos de baja performance en nuestras páginas ASP.net.
Ciertamente me parece un muy buen post y no tendría sentido en redundar algo que esta mas que claro, aquí la dirección.

Como información complementaría podemos preguntarle primero a Google, es recomendable darse una vuelta por los primeros enlaces, se ven realmente interesantes, aqui unos que a pesar de la fecha de publicacion, tienen un espacio aqui:
10 Tips for Writing High-Performance Web Applications: Rob Howard via mdsnmag nos muestra desde otra perspectiva los aspectos a considerarse en la performance de nuestra aplicacion web. Aqui el enlace.
Performance Tips and Tricks in .NET Applications: Este artículo si que tiene su tiempo!, pero es tanta la información publicada que estoy seguro que a muchos les sorprenderá darle una primera revisada. Aquí el enlace.

YSlow
Ya que hablamos de performance en aplicaciones web, han usado YSlow?, es una extensión del Firebug que nos permite realizar una revision del cumplimiento de ciertas reglas de performance que deberían cumplir todas las aplicaciones (si, todas).
Y de que reglas hablamos, pues, principios básicos que van de la mano con buen uso de las librerias js o css, o de la cantidad de kb transferidas al navegador cliente.
Lo interesante de todo esto, es que el tratamiento de esta herramienta no se hace simulando la ejecucion del sitio web, lo que se hace es instalar el componente en el navegador, poner la url, y mientras vamos viendo nuestra página, este componente, nos muestra gráficamente desde la descarga hasta el cumplimiento de las reglas de performance.

Pues bien, este componente ha sido desarrollado por los chicos de Yahoo (hellooow Microsoft!), y de momento se integra al Firebug (hellooow Microsoft!), es decir, compatible con FireFox (well you know I mean). Aunque esperemos que siga abierta la posibilidad de un futuro cercano al Internet Explorer.
Aqui la página del YSlow, personalmente me parece muy buena, sirviendo ademas como alternativa si es que se quiere probar ciertos aspectos de nuestra aplicacion sin necesidad de instalar herramientas sofisticadas en cualquier pc.
Les dejo ademas la página de las reglas de performance que se buscan cumplir, estas se encuentran agrupadas por categorías que siempre debemos tomar en cuenta.
Termino esta bloque de “La Caja” con el blog de los chicos de Yslow. De por si, se trata de los chicos de performance en Yahoo!.

Enterprise Architecture Guide
Ciertamente el libro se llama “A Practical Guide to Enterprise Architecture”, el cual probablemente muchos de ustedes ya hayan revisado, leido. Por mi parte lo tengo desde hace poco y me parece muy interesante, los ejemplos o historias que se muestran allí dentro son cercanas a la realidad y nos dan una idea de que aspectos considerar de ahora en adelante.
Este pequeño libro, demasiado separado del código nos da una vision de que mas realizar o que debemos tomar en cuenta si es que deseamos continuar con nuestro trabajo relacionado con la Arquitectura del Software. Y, les comento, nuevamente, no hay nada de código alli dentro.

 

Está de más decir que fue completamente escrito por Arquitectos.

Comentarios.
Bueno, sin mas me despido, ha sido una semana muy larga y tengo entendido que vendrán muchos días asi de interesantes. De momento les comento que sería bueno, para muchos de mis amigos, y quizá para usted amigo lector (si, tu, el que esta en la laptop, aunque sea solo uno, se que está alli) que revise este enlace, el cual es el nexo a un post titulado “Metrosexual Developer”.
Un Saludo.

Jersson[at]Casa
Cross from here

Cómo nace un paradigma?

Cada cierto tiempo termino una conversación comentando entre dientes “saquemos ese paradigma de la mente”, pero exactamente que es un paradigma?
Es acaso una regla o una manera de pensar que nos encaja a un contexto que muchas veces nos obliga a responder de la mejor manera?

Como saberlo, a veces lo relacionan hasta con leyendas, formas de vida, métodos que nadie puede cambiar, pues asi estan y asi funcionan.

Esas ultimas palabras no suenan conocidas?
Pues bien, aquí un documento que recibí hace mucho tiempo.
Espero les sirva.

Saludos[at]Cama
Cross from here