Carlos Walzer : Performance

Materiales: Mejoras de Desempeño de Aplicaciones .NET

cwalzer — Wed, 18 Mar 2009 17:09:00 GMT

Aqui están los materiales de la charla "Mejoras de Desempeño de Aplicaciones .NET" dictada ayer en el Microsoft User Group de Argentina.

Presentación

Esta es la zaga de artículos que tratan las técnicas utilizadas en la charla:

Materiales: Code Camp Buenos Aires 2008

cwalzer — Sat, 04 Oct 2008 11:12:00 GMT

Aqui están los materiales de la charla "Mejoras de Desempeño de Aplicaciones .NET" dictada hoy en el CodeCamp Buenos Aires 2008. (A propósito, impresionado por la cantidad de asistentes).

Presentación

Esta es la zaga de artículos que tratan las técnicas utilizadas en la charla:

CodeCamp - Buenos Aires 2008

cwalzer — Thu, 11 Sep 2008 00:29:00 GMT

Evento Académico gratuito con más de 40 conferencias sobre tecnologías Microsoft dicatadas por referentes de la industria.

Fecha:	Saturday, October 4, 2008
Hora:	10:00am - 7:00pm
Lugar:	UAI
Dirección:	San Juan 983
Ciudad:	Buenos Aires, Argentina

Descripción

• Novedades en Tecnologías Microsoft
• Más de 40 conferencias técnicas de Referentes de la Industria
• Sorteos entre los asistentes

Más detalles en el sitio del evento: http://www.microsoft.com.ar/codecamp/

Agenda:

10:00 a 10:30 Registración - Recepción

10:30 a 11:00 Apertura y revisión de agenda

11:15 a 12:15
Programando por un sueño - Patricio Jutard
Introducción a ASP.NET MVC - Pablo Cibraro
Videojuegos Multiplataforma con XNA - Augusto Chesini
Todo Lo Que Hay Que Saber Acerca De Linq - Matías Bonaventura
Mejoras De Desempeño De Aplicaciones .Net - Carlos Walzer
Gestión De Proyectos De Software: Un Enfoque Práctico - Maximiliano Menasches e Ignacio López
Windows Presentation Foundation Para Desarrolladores - Andres Aguiar
Python En La Plataforma .Net - Martín Salías
Introducción A Grafos - Pablo Gauna
Wamp - Maximo Naccarato
IIS7 4x4 - Alberto Ortega Y Horacio Gonzalez

12:30 a 13:30
Andamios en la web: Desarrollo ágil con ASP.NET Dynamic Data - Miguel Saez
Desarrollo web multi-capa con Volta: un paso hacia adelante - Pablo Zaidenvoren Y Rodolfo Finochietti
Wpf 3d Y Física - Damián Galletini
Microsoft Sql Server 2008 – Introducción A “Microsoft Sql Server Data Platform” - Johnny Halife
Patrones De Arquitectura Con C# - Matías Iacono
Vsts Y Scrum - Daniel Zacharias
Creando Aplicaciones En Wpf - José Villagrán
Parallel Extensions - Nicolás Padula Y Mauricio Lopez
Entorno De Desarrollo Para Windows Mobile 6 - Leonardo Natale
Windows Server 2008 + Iis 7 - Augusto Alvarez
Desmitificando Windows Vista - Mariano Rempel

13:30 a 14:45
Almuerzo – Demo Fest

15:00 a 16:00
El futuro de la ingeniería de software - Santiago Ceria
Silverlight 2.0 Beta 2 - Construyendo Aplicaciones Web Atractivas Utilizando Microsoft Silverlight - Ivana Tilca
3d Games Technology: Computer Animation - Diego Park
Ado.Net Entity Framework En Acción - Maximiliano Menasches Y Hernán Nobile
Técnicas Para Mejorar La Performance En Sitios Web - Juan Ladetto
Scrum - Patricio Jutard
¿Qué Es "Wpf/E"? - Luis Perdomo
Reconocimiento Facial - Armando Meabe
Novedades De Vs 2008 Y Cf 3.5 Para Wm6 - Leonardo Natale
Introducción A La Administración De Sucursales Con Windows Server 2008 - Leonardo Amaya
Seguridad En Windows Server 2008 - Leandro Amore

16:15 a 17:15
Hyper-V en acción - Alejandro Ponicke Y Leandro Amore
Expression Blend - Marcelo Quevedo
Qué Es Linq? - Guillermo Delfino
Programación Intuitiva De Xml En El Marco .Net (Xlinq) - Mauricio Grimberg
Howto: Performance Y Load Testing - Matias Woloski Y Federico Boerr
¿Cómo Lograr Un Proyecto Exitoso? - Patricia Scalzone
Construcción De Servicios Rest Con Wcf - Pablo Cibraro
Microsoft Robotics Studio - Mauro Castagnasso
Introducción A Los Conceptos De Generics Y Delegates - Ezequiel Cura
Monitoreo De Aplicaciones Heterogéneas - Alberto Ortega
Instalando Windows Vista - Francisco Moura

17:15 a 18:30
Break – Demo Fest

18:45 a 20:00
Cierre del Evento y Sorteos

Video: Load Test en Visual Studio 2008

cwalzer — Fri, 01 Aug 2008 04:29:00 GMT

Como preparar, correr y analizar un Web Test utilizando Visual Studio 2008 Team Systems.

Duración: 12:59

Extraído del Lanzamiento de Visual Studio 2008

Video: Mejora de Desempeño (Performance Tuning) con Visual Studio 2008 Team Systems

cwalzer — Mon, 28 Jul 2008 08:47:00 GMT

Este video muestra como mejorar el desempeño (Perfoemance Tuning) de las aplicaciones .NET detectando cuellos de botella con Visual Studio Team System 2008

Duración: 7:51

Extraído del Lanzamiento de Visual Studio 2008

Vídeo: Herramientas para asegurar la calidad utilizando Visual Studio Team System 2008

cwalzer — Wed, 25 Jun 2008 17:56:00 GMT

Durante el lanzamiento de Visual Studio 2008, he grabado un vídeo exponiendo las Herramientas para asegurar la calidad utilizando Visual Studio Team System 2008.

Allí hago una presentación sobre el aseguramiento de calidad y reviso las técnicas y herramientas propuestas por Visual Studio 2008. Además hago un repaso por:

Testing (WebTest, LoadTest)
Análisis de Rendimiento (Profiler, Performance)
Profiling de Código (Code)
Técnicas de analisis el código ( Managed Code Analisys Tool, FxCop)
Métricas de código (Code Metrics).

El vídeo está disponible para bajarlo o verlo en línea.

Además puedes bajar el código y la presentación desde aquí.

Performance: Datos en Memoria con ADO.NET IV

cwalzer — Tue, 20 May 2008 23:50:00 GMT

En este artículo quisiera mostrarles cual es el consumo de memoria de algunas técnicas de acceso a datos. En artículos anteriores hemos estudiado y optimizado performance mejorando el tiempo de procesamiento. Como colorario veremos algunos gráficos que siempre ayudan a la comparación.

Este artículo está relacionado con:

Presentación del escenario

Este es el contexto en el que estoy haciendo las mediciones:

Una aplicación Windows Forms, que utiliza 4 mecanismos para recuperar datos “de solo lectura” de la base de datos AdvertureWorks alojada en SQL Server 2005:

DataReader cargado en una lista genérica de objetos de entidad
DataSet
DataTable
DataSet tipificado creado con el asistente de Visual Studio 2005

Aquí subrayo “solo lectura” porque, justamente solo quiero recuperar los datos, y no hacer ninguna operación sobre ellos.

Memoria y Garbage Collector

Si bien sabemos que la administración de la memoria en .NET es un trabajo que le compete al Garbage Collector y que no es terreno en el que debamos hurgar, a no ser que sea por administración de memoria no manejada, siempre es bueno saber que uso hacemos de él. Si bien el Garbage Collector es un mecanismo muy optimizado, y hace un muy buen trabajo de recolección de basura (memoria no utilizada), tiene sus limitaciones y su costo. Sería una buena actitud de parte nuestra considerar al Garbage Collector como un recurso más, así como lo es la memoria. Teniendo en cuenta esto lograríamos minimizar su trabajo, lo cual redundaría en un mejor rendimiento de nuestra aplicación.

El Código

La versión completa del código podrás bajarla de aquí. De todas formas démosle un vistazo:

Esta es la sentencia sql a ejecutar en la base de datos AdventureWorks:

Select HumanResources.Employee.EmployeeID, Person.Contact.FirstName,
          Person.Contact.MiddleName, Person.Contact.LastName,
          HumanResources.Employee.Title, HumanResources.Employee.BirthDate,
          Person.Address.AddressLine1, Person.Address.AddressLine2,
          Person.Address.City, Person.Address.PostalCode, Person.Contact.EmailAddress,
          Person.Contact.Phone, HumanResources.Employee.MaritalStatus, HumanResources.Employee.Gender
          FROM HumanResources.Employee
          INNER JOIN Person.Contact ON HumanResources.Employee.ContactID = Person.Contact.ContactID
          INNER JOIN HumanResources.EmployeeAddress ON HumanResources.Employee.EmployeeID = HumanResources.EmployeeAddress.EmployeeID
          INNER JOIN Person.Address ON HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID
          AND HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID

La clase DataAccess

public class DataAccess
{
    static readonly string _connString;
    static readonly string _sqlCmd;

    static DataAccess()
    {
        _connString = "Password=;User ID=sa;Initial Catalog=AdventureWorks;Data Source=WALZER3";
        //Obtengo la sentencia SQL que está en el archivo de texto Consulta.sql
        StreamReader sr = new StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream("Walzer.Antipracticas.Consulta.sql"));
        _sqlCmd = sr.ReadToEnd();
    }

    static public DataSet TraerDataSet()
    {
         DataSet ds = null;
         try
         {
              using (SqlConnection conn = new SqlConnection(_connString))
              {
                  conn.Open();
                  SqlCommand cmd = new SqlCommand();
                  cmd.CommandText = "GetEmployees";
                  cmd.Connection = conn;
                  cmd.CommandType = CommandType.StoredProcedure;
                  SqlDataAdapter da = new SqlDataAdapter(cmd);
                  ds = new DataSet();
                  da.Fill(ds);
              }
         }
         catch
         {
         }
         return ds;
     }

     static public List<Employee> TraerEmployeesOptimizado()
     {
          List<Employee> employees = new List<Employee>();
          try
          {
          using (SqlConnection conn = new SqlConnection(_connString))
          {
              SqlCommand cmd = new SqlCommand();
              cmd.CommandText = "GetEmployees";
              cmd.Connection = conn;
              cmd.CommandType = CommandType.StoredProcedure;
              conn.Open();
              using (SqlDataReader dr = cmd.ExecuteReader())
              {
                  int colEmployeeId = dr.GetOrdinal("EmployeeId");
                  int colFirstName = dr.GetOrdinal("FirstName");
                  // Omito las líneas similares por cuestión de lectura
                  int colCount = dr.FieldCount;
                  object[] values = new object[colCount];
                  while (dr.Read())
                  {
                    Employee employee = new Employee();
                    dr.GetValues(values);
                    employee.EmployeeID = Convert.ToInt32(values[colEmployeeId]);
                    employee.FirstName = Convert.ToString(values[colFirstName]);
                    employees.Add(employee);
                  }
                }
             }
          }
          catch
          {
          }
          return employees;
     }

     static public DataTable TraerDataTableOptimizado()
     {
          //Este método está optimizado para cargar un DataTable con datos de SOLO LECTURA
          DataTable dt = null;
          try
          {
               using (SqlConnection conn = new SqlConnection(_connString))
               {
                    conn.Open();
                    SqlCommand cmd = new SqlCommand();cmd.CommandText = "GetEmployees";
                    cmd.Connection = conn;
                    cmd.CommandType = CommandType.StoredProcedure;
                    SqlDataAdapter da = new SqlDataAdapter(cmd);dt = new DataTable();
                    da.Fill(dt);
               }
          }
          catch
          {
          }
          return dt;
     }
}

El DataSet tipificado fue creado arrastrando la consulta SQL sobre la superficie de diseño del DataSet, lo único que escribí fue las siguientes líneas para cargar el DataSet tipificado:

DsEmployeesTableAdapters.GetEmployeesTableAdapter da = new Walzer.Antipracticas.DsEmployeesTableAdapters.GetEmployeesTableAdapter();
_dsEmployees = da.GetData();

Lectura del uso de Memoria

Vamos medir el uso de memoria de cada una de estas técnicas de acceso a datos utilizando 3 herramientas:

El CLR Profiler nos revela en una primera lectura de 290 registros representados en memoria por cada una de las técnicas.

En este gráfico podemos observar que el objeto del tipo AntiPracticas.frmMemoria, que es nuestra ventana, y sus referenciados consumen 836 Kb. Aunque la variable que apunta a esta estructura es de solo 368 bytes.

AntiPracticas.frmMemoria tiene cuatro campos privados que apuntan a:

un DataSet Tipado (DsEmployees.GetEmployeesDataTable): 313 Kb
un DataSet (Data.DataSet): 185 Kb
un DataTable (Data.DataTable ): 184 Kb
una colección genérica de objetos del tipo Employee (Generic.List<T>): 138 Kb

Aquí mismo podemos apreciar que el DataSetTipado es la estructura más costosa en cuanto a consumo de memoria. Que no hay casi diferencia entre un DataSet y un DataTable, y que la colección de objetos es la más barata. No está demás destacar que todas las estructuras contienen “los mismos datos”.

La misma información podemos verla en JetBrains DotTrace.

Observen la columna “Held Memory, bytes”, que es la memoria referenciada por cada instancia:

_dsEmployees (Walzer.Antipracticas.DsEmployees.GetEmployeesDataTable)
_ds (System.Data.DataSet)
_dt (System.Data.DataTable)
_employees (System.Collection.Generic.List<Employee>)

Estructura de Objetos en memoria

Comparemos en las siguientes dos capturas la complejidad de una y otra estructura, las cuales almacenan los mismos datos, de solo lectura en nuestro caso.

La primera figura nos muestra la lista genérica _employees, la cual está implementada internamente por un vector de _items, que contiene un conjunto de objetos Employee, la cual contiene finalmente los datos.

Observemos ahora la estructura de un DataSet tipificado, y el camino para llegar al dato final.

La estructura es mucho más compleja, pero no perdamos de vista que un DataSet fue diseñado con la premisa de propósito general, y mucho de su funcionalidad es útil. Debemos usar nuestro criterio a la hora de decidir que es mejor para nuestro sistema.

Inspeccionado contenido de las variables

Usemos ahora la herramienta .NET Memory Profiler para ver el contenido de un objeto del tipo Employee. Esta figura nos muestra las referencias a la que hace este objeto, que son System.String.

Pero, ¿dónde está el campo _idEmployee que es del tipo int o _birthDate que es de tipo DateTime? Bien, estos están contenidos en el mismo espacio de memoria que el objeto del tipo Employee ya que son tipos básicos, int y ulong respectivamente. En cambio System.String es una referencia al espacio de memoria donde está guardada la cadena de caracteres. La solapa Field Values nos muestra el contenido de la instancia #12,729 del objeto del tipo Employee. Además de esta información podemos apreciar, cuales son los caminos al Root de este objeto, y cuál fue el Call Stack que instanció este objeto en memoria.

Cantidad de Objetos referenciados

Un dato que no es menor aquí es el que nos muestra la columna “Held Objects”. Esta nos dice cuantos objetos son referenciados en toda la estructura en memoria.

En este caso la cantidad de filas en memoria para cada estructura es de 10, valor que se asemeja más a la realidad, ya que no es buena práctica pasar todas las filas del resultado entre capas, sino usar técnicas de paginación.

_dsEmployees (Walzer.Antipracticas.DsEmployees.GetEmployeesDataTable): 320
_ds (System.Data.DataSet): 213
_dt (System.Data.DataTable): 206
_employees (System.Collection.Generic.List<Employee>): 122

Más allá de la cantidad de memoria en bytes, la cantidad de objetos referenciados nos da una idea del trabajó que tendrá el Garbage Collector al momento de deshacerse de estos objetos. Cuantas más referencias en memoria, más recursos consumidos por este algoritmo.

Comparación de resultados

Veamos una serie de gráficos que resumen las lecturas realizadas. Tomé lecturas de 290 registros, 10 registros (que es el típico caso del tamaño de una página cuando se realiza paginación) y 1 registro.

Bytes en Memoria	290 reg	10 reg	1 reg
DataSet	189112	19028	14856
DataTable	188848	18764	14588
List<>	141774	4790	514
DataSet Tipado (wizard)	319478	33114	28902

Fig1: Tabla Comparativa de Bytes en Memoria

Fig2: Bytes en memoria para 290 registros

Fig3: Bytes en memoria de 10 y 1 registro.

Referencias	290 reg	10 reg	1 reg
DataSet	3581	213	105
DataTable	3574	206	98
List<>	3477	122	13
DataSet Tipado (wizard)	3788	300	192

Fig4: Tabla Comparativa de Objetos Referenciados

Fig5: Instancias referenciadas para 290 registros

Fig6: Instancias referenciadas para 10 y 1 registro

Estos gráficos muestran claramente que la técnica más económica es pasar entre capas una lista genérica de un tipo específico. Y que la ferretería utilizada por las estructuras del tipo DataSet se puede despreciar cuanto mayor es el volumen que contienen.

Conclusión

Hemos comprobado que el uso correcto de las técnicas de acceso a datos en ADO.NET nos permite lograr un mayor rendimiento en nuestras aplicaciones. También hemos aprendido algo de cómo funciona internamente ADO.NET, y como son las estructuras en memoria y el uso que se hace de ellas.

Siempre es bueno conocer cómo funcionan internamente los frameworks que utilizamos para construir nuestras aplicaciones para poner en la balanza, facilidad y agilidad de uso contra rendimiento y consumo de recursos.

Anti Prácticas .NET: Lectura de Datos con ADO.NET III

cwalzer — Mon, 12 Nov 2007 17:26:00 GMT

Esta es la última entrega de esta zaga. En este artículo haré un resumen de lo investigado, las mejoras que hemos encontrado para mejorar el rendimiento de Lectura de Datos con ADO.NET, y haremos algunos gráficos comparativos que siempre ayudan a visualizar mejor la comparación.

Este artículo es una continuación de los artículos anteriores:
Anti Prácticas .NET: Lectura de Datos con ADO.NET
Anti Prácticas .NET: Lectura de Datos con ADO.NET II

Presentación del escenario

Este es el contexto en el que estoy haciendo las mediciones:
Una aplicación Windows Forms, que utiliza 4 mecanismos para recuperar datos “de solo lectura” de la base de datos AdvertureWorks alojada en SQL Server 2005:

DataReader cargado en una lista genérica de objetos de entidad
DataSet
DataTable
Dataset tipificado creado con el asistente de Visual Studio 2005

Aquí subrayo “solo lectura” porque, justamente solo quiero recuperar los datos, y no hacer ninguna operación sobre ellos.

En realidad las 3 primeras técnicas fueron descriptas en los artículos anteriores. En este se agrega la carga del DataSet tipificado. Por lo menos mi experiencia me dice que los Asistentes crean código no muy optimizado que digamos. Así que llamemos de nuevo al “Cazador de Mitos .NET”, que nos dirá:

Vamos a la caza del mito: “El código generado por un asistente no desempeña un buen rendimiento”

El Código

La versión completa del código podrás bajarla de aquí. De todas formas démosle un vistazo:

Esta es la sentencia sql a ejecutar en la base de datos AdventureWorks:

Select HumanResources.Employee.EmployeeID, Person.Contact.FirstName
       Person.Contact.MiddleName, Person.Contact.LastName,
       HumanResources.Employee.Title, HumanResources.Employee.BirthDate,
       Person.Address.AddressLine1, Person.Address.AddressLine2,
       Person.Address.City, Person.Address.PostalCode, Person.Contact.EmailAddress,
       Person.Contact.Phone, HumanResources.Employee.MaritalStatus, HumanResources.Employee.Gender
       FROM HumanResources.Employee
       INNER JOIN Person.Contact
          ON HumanResources.Employee.ContactID = Person.Contact.ContactID
       INNER JOIN HumanResources.EmployeeAddress
          ON HumanResources.Employee.EmployeeID = HumanResources.EmployeeAddress.EmployeeID
       INNER JOIN Person.Address
          ON HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID
          AND HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID

El DataSet tipificado fue creado arrastrando la consulta SQL sobre la superficie de diseño del DataSet, lo único que escribí fue las siguientes líneas para cargar el DataSet tipificado:

private void button1_Click(object sender, EventArgs e)
{
   DsEmployees.GetEmployeesDataTable dsEmployees;
   DsEmployeesTableAdapters.GetEmployeesTableAdapter da = new DsEmployeesTableAdapters.GetEmployeesTableAdapter();
   dsEmployees = da.GetData();
}

Lectura del DataSet tipificado

Vamos a medir el tiempo que consume la carga del DataSet tipificado. Para ello recordemos que la consulta devuelve 290 regitros y que la ejecuto 10 veces.

El tiempo consumido es de 7618,5 ms. Recuerda que la lectura anterior del DataSet era 2386 ms, para el DataTable 2369 ms y para el List<> 1883 ms.Creo que realmente no vale la pena hacer un estudio para saber internamente dónde está el mayor consumo, puesto que el uso de asistentes nunca fue una práctica recomendada.

¡Mito cazado! J. El código generado por un asistente no desempeña un buen rendimiento.

Comparación de resultados

Fig1: Tabla Comparativa

Fig2: Lectura de 290 registros

Fig3: Lectura de 10 y 1 registro.

Estos gráficos muestran claramente que la técnica más rápida es la carga de una lista genérica List<> de objetos de Entidades; técnica utilizada en capas de acceso a datos DALs (Data Access Layers), y la encontraremos por varios sitios como mejor práctica.

Resumen de las mejoras realizadas

La primera mejora realizada fue respecto de la carga de un DataTable. En ese caso habíamos detectado que la carga de un DataTable StandAlone era más lento que la de un DataSet. Para mejorar el tiempo habíamos reemplazado la llamada DataTable.Load() por el uso de un DataAdapter.Fill(dataTable). El DataAdapter está optimizado para solo lectura de manera predeterminada.

La segunda mejora tiene que ver con la carga del List<>. Allí habíamos detectado que llamadas a GetOrdinal() dentro del bucle que podían obviarse, justamente obteniendo el ordinal de la columna antes de lanzar el bucle. Y la otra mejora era obtener todos los valores de la columnas de una fila con el método GetValues(vector), y luego tomar los datos del vector.

LINQ to SQL

Me hubiese gustado poder comparar en esta serie de artículos el uso de LINQ to SQL y Entity Data Framework, pero no sería muy preciso hacerlo con un código beta. Como decía no podemos comparar, pero si ver que es lo más optimo dentro de LINQ to SQL. Para ello, te recomiendo un artículo del maestro Daniel Seara.

Conclusión

Hemos comprobado que el uso correcto de las técnicas de acceso a datos en ADO.NET nos permite lograr un mayor rendimiento en nuestras aplicaciones. También hemos aprendido algo de cómo funciona internamente ADO.NET, ejercicio que nos va a servir para tomar buenas decisiones al momento de elegir nuestra estrategia de acceso a datos.

La próxima entrega tendrá que ver con el consumo de memoria que estás técnicas hacen.

Anti Prácticas .NET: Lectura de Datos con ADO.NET II

cwalzer — Tue, 30 Oct 2007 10:21:00 GMT

Dada la sugerencia de Sergio Tarrillo, en este artículo mediremos la lectura de datos de una base de datos con ADO.NET, incluyendo la carga de una lista genérica List<> de objetos de entidad.Este artículo es una continuación del artículo anterior Anti Prácticas .NET: Lectura de Datos con ADO.NET

Presentación del escenario

Este es el contexto en el que estoy haciendo las mediciones:Una aplicación Windows Forms, que utiliza 3 mecanismos para recuperar datos “de solo lectura” de la base de datos AdvertureWorks alojada en SQL Server 2005:

DataReader cargado en una lista genérica de objetos de entidad
DataSet
DataTable Aquí subrayo “solo lectura” porque, justamente solo quiero recuperar los datos, y no hacer ninguna operación sobre ellos.

El Código

La versión completa del código podrás bajarla de aquí. De todas formas démosle un vistazo:
Esta es la sentencia sql a ejecutar en la base de datos AdventureWorks:

Select HumanResources.Employee.EmployeeID, Person.Contact.FirstName
       Person.Contact.MiddleName, Person.Contact.LastName,
       HumanResources.Employee.Title, HumanResources.Employee.BirthDate,
       Person.Address.AddressLine1, Person.Address.AddressLine2,
       Person.Address.City, Person.Address.PostalCode, Person.Contact.EmailAddress,
       Person.Contact.Phone, HumanResources.Employee.MaritalStatus, HumanResources.Employee.Gender
       FROM HumanResources.Employee
       INNER JOIN Person.Contact
          ON HumanResources.Employee.ContactID = Person.Contact.ContactID
       INNER JOIN HumanResources.EmployeeAddress
          ON HumanResources.Employee.EmployeeID = HumanResources.EmployeeAddress.EmployeeID
       INNER JOIN Person.Address
          ON HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID
          AND HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID

y la clase DataAccess:

namespace Walzer.Antipracticas{
    public class DataAccess
    {
        static readonly string _connString;
        static readonly string _sqlCmd;

        static DataAccess()
        {
            _connString = "Password=;User ID=;Initial Catalog=AdventureWorks;Data Source=WALZER3";
            //Obtengo la sentencia SQL que está en el archivo de texto Consulta.sql
            StreamReader sr = new StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream("Walzer.Antipracticas.Consulta.sql"));
            _sqlCmd = sr.ReadToEnd();
        }

        static public DataSet TraerDataSet()
        {
            DataSet ds = null;
            try
            {
                using (SqlConnection conn = new SqlConnection(_connString))
                {
                    conn.Open();
                    SqlCommand cmd = new SqlCommand();
                    cmd.CommandText = _sqlCmd;
                    cmd.Connection = conn;
                    cmd.CommandType = CommandType.Text;
                    SqlDataAdapter da = new SqlDataAdapter(cmd);
                    ds = new DataSet();
                    da.Fill(ds);
                }
            }
            catch {}
            return ds;
        }

        static public List<Employee> TraerEmployees()
        {
            List<Employee> employees = new List<Employee>();
            try
            {
                using (SqlConnection conn = new SqlConnection(_connString))
                {
                    SqlCommand cmd = new SqlCommand();
                    cmd.CommandText = _sqlCmd;
                    cmd.Connection = conn;
                    cmd.CommandType = CommandType.Text;
                    conn.Open();
                    using (SqlDataReader dr = cmd.ExecuteReader())
                    {
                        while (dr.Read())
                        {
                            Employee employee = new Employee();
                            employee.EmployeeID = Convert.ToInt32(dr["EmployeeId"]);
                            employee.FirstName = Convert.ToString(dr["FirstName"]);
                            //Por motivos de espacio obvié las lineas restantes…
                            employees.Add(employee);
                        }
                    }
                }
            }
            catch {}
            return employees;
        }

        static public DataTable TraerDataTableOptimizado()
        {
            //Este método está optimizado para cargar un DataTable con datos de SOLO LECTURA
            DataTable dt = null;
            try
            {
                using (SqlConnection conn = new SqlConnection(_connString))
                {
                    conn.Open();
                    SqlCommand cmd = new SqlCommand();
                    cmd.CommandText = _sqlCmd;
                    cmd.Connection = conn;
                    cmd.CommandType = CommandType.Text;
                    SqlDataAdapter da = new SqlDataAdapter(cmd);
                    dt = new DataTable();
                    da.Fill(dt);
                }
            }
            catch {}
            return dt;
        }
     }
}

Comparación de Técnicas

Lo que primero vamos a medir es el tiempo que consume cada uno de las técnicas de lectura de datos. Para ello recordemos que la consulta devuelve 290 regitros y que ejecuto 10 veces cada método.

Podemos observar entonces que no hay mayor diferencia entre las técnicas. Claro que ya hemos optimizado en el artículo anterior la lectura del DataTable.

Optimización de la carga de una lista genérica de objetos de entidad con DataReader

De todas formas sería bueno revisar el método TraerEmployees, que carga una List<Employee> para ver si le cabe alguna optimización.

Encontramos aquí que tenemos 446 ms. + 74 ms. en 34800 + 5800 invocaciones a GetOrdinal() debido a la forma en que recuperamos el valor de la columna dr["nombreCampo"]. GetOrdinal devuelve la posición de la columna para ese nombre campo, y esto es muy conveniente. No es recomendable reemplazar el nombre de la columna por el número de la misma al recuperar el dato, ya que cualquier cambio en la consulta SQL invalidaría nuestro código. Lo que debemos hacer entonces es minimizar la cantidad de llamadas. Quitemos la invocaciones a GetOrdinal() de adentro del bucle.

static public List<Employee> TraerEmployeesOptimizado1()
{
    List<Employee> employees = new List<Employee>();
    try
    {
        using (SqlConnection conn = new SqlConnection(_connString))
        {
            SqlCommand cmd = new SqlCommand();
            cmd.CommandText = _sqlCmd;
            cmd.Connection = conn;
            cmd.CommandType = CommandType.Text;
            conn.Open();
            using (SqlDataReader dr = cmd.ExecuteReader())
            {
                int colEmployeeId = dr.GetOrdinal("EmployeeId");
                int colFirstName = dr.GetOrdinal("FirstName");
                //Por motivos de espacio obvié las lineas restantes…
                while (dr.Read())
                {
                    Employee employee = new Employee();
                    employee.EmployeeID = Convert.ToInt32(dr[colEmployeeId]);
                    employee.FirstName = Convert.ToString(dr[colFirstName]);
                    //Por motivos de espacio obvié las lineas restantes…
                    employees.Add(employee);
                }
            }
        }
    }
    catch {}
    return employees;
}

Revisemos el profiling de código del código optimizado:

Hemos bajado el tiempo de 2631 ms. a 2132 ms. y reducido las invocaciones a GetOrdinal() a las necesarias: 14 invocaciones -> 14 campos.La segunda reducción que podríamos hacer corresponde con get_MetaData(), la cual se invoca por registro y por columna. La intención de minimizar esta llamada es la siguiente: ¿Para qué leer la “metadata” una y otra vez si el esquema de los datos no varía en un set de resultados de solo lectura como es el DataReader? ¿Cómo podemos hacer para reducir la cantidad de invocaciones?. Bien, mi sugerencia es tratando de reducir las invocaciones a GetValue() que internamente llama a get_MetaData(), reemplazándola por GetValues(object[]), la cual lee los datos del registro de una vez y devuelve un vector con los resultados.

static public List<Employee> TraerEmployeesOptimizado2()
{
    List<Employee> employees = new List<Employee>();
    try
   {
        using (SqlConnection conn = new SqlConnection(_connString))
        {
            SqlCommand cmd = new SqlCommand();
            cmd.CommandText = _sqlCmd;
            cmd.Connection = conn;
            cmd.CommandType = CommandType.Text;
            conn.Open();
            using (SqlDataReader dr = cmd.ExecuteReader())
            {
                int colEmployeeId = dr.GetOrdinal("EmployeeId");
                int colFirstName = dr.GetOrdinal("FirstName");
                //Por motivos de espacio obvié las lineas restantes…
                int colCount = dr.FieldCount;
                object[] values = new object[colCount];
                while (dr.Read())
                {
                    Employee employee = new Employee();
                    dr.GetValues(values);
                    employee.EmployeeID = Convert.ToInt32(values[colEmployeeId]);
                    employee.FirstName = Convert.ToString(values[colFirstName]);
                    //Por motivos de espacio obvié las lineas restantes…
                    employees.Add(employee);
                }
            }
        }
    }
    catch {}
    return employees;
}

Si observamos ahora el profiler vemos que las invocaciones a get_MetaData() se hacen por registro y no por columna.

Con esta segunda optimización, hemos logrado reducir el tiempo 2631 ms. a 1883 ms., disminuyendo las invocaciones a get_MetaData() de 4060 a 290. Logramos entonces una reducción del 40%.

Conclusión

Hemos comprobado que el uso correcto de las técnicas de acceso a datos en ADO.NET nos permite lograr un mayor rendimiento en nuestras aplicaciones. También hemos aprendido algo de cómo funciona internamente ADO.NET, ejercicio que nos va a servir para tomar buenas decisiones al momento de elegir nuestra estrategia de acceso a datos.

Queda para una tercera entrega ver el costo de acceder a los datos usando los Asistentes de Visual Studio 2005. Allí haré un resumen de lo investigado, para que tengan en cuenta al momento de diseñar su estrategia de acceso a datos.

Continuación

Parte III

MSDN Radio en Vivo: Discusión: Técnicas y Herramientas para Mejorar el Rendimiento de Aplicaciones y Bases de Datos

cwalzer — Fri, 26 Oct 2007 14:44:00 GMT

Durante el último mes los expertos de Solid Quality Mentors han estado discutiendo técnicas para medir y mejorar el rendimiento de las aplicaciones. Durante este show de MSDN Radio únase a una discusión en vivo sobre cómo optimizar sus aplicaciones, herramientas para medir el rendimiento, mejores técnicas de acceso a datos, tips de optimización de código en SQL Server y cómo mejorar el rendimiento de OLAP y Analysis Server.

Te esperamos para que puedas evacuar tus dudas y debatir acerca de como mejorar el rendimiento de tus aplicaciones .NET y bases de datos.
http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032357579&EventCategory=4&culture=es-AR&CountryCode=AR

Aprovecho la oportunidad para invitarlos a que vean el WebCast de Gustavo Larriera sobre el tema:
Técnicas de ajuste de rendimiento en SQL Server 2005

Jornada en Bs As: Mejoras de desempeño de aplicaciones .NET

cwalzer — Mon, 22 Oct 2007 17:18:00 GMT

Veremos cómo detectar y diagnosticar problemas de desempeño y mal uso de la memoria de aplicaciones .NET.

DETALLES DE CONTENIDOS:
Uno de los desafíos a tener en cuenta a la hora de desarrollar medianas y grandes aplicaciones, es lograr una buen desempeño de las mismas en un ambiente de producción, y la posibilidad de escalabilidad que la misma tenga al presentarse el crecimiento del negocio. Por lo tanto, es importante tener en cuenta estos aspectos en el ciclo de vida de una aplicación conociendo las técnicas y herramientas disponibles para lograrlo. Veremos cómo detectar y diagnosticar problemas de desempeño y mal uso de la memoria de aplicaciones .NET, utilizando técnicas como: lectura de información de instrumentación, profiling de código, profiling de memoria, depuración de HTTP, ejecución de test de carga y stress y Tracing de ASP.NET y SQl Server.

Viernes 2 de Noviembre de 2007 de 18.00 a 22.00 hs.
Lugar: Auditorio MUG - Rivadavia 1479 1º Piso - Oficina A, Buenos Aires - Argentina
Registrate

Capacitación en Línea Gratuita

cwalzer — Fri, 19 Oct 2007 20:00:00 GMT

En Solid Quality Learning estamos probando una nueva modalidad de cursos en línea, utilizando LiveMeeting 2007, de la misma forma que lo hace Microsoft con sus Webcasts.

Para poder probar la experiencia, hemos abierto 5 entrenamientos gratuitos de 4 horas de duracion (2 sesiones de 2 horas cada uno).

Los temas a escoger son:

Mejoras de desempeño de aplicaciones (dictado por Carlos Walzer, el 21 de noviembre)
Opciones para la Administración de Transacciones en .NET Framework y SQL Server (dictado por Adolfo Wiernik el 3 de diciembre)
Bodegas de Datos (Data Warehouse) e Inteligencia de Negocios para DBAs (dictado por Javier Loria el 4 y 6 de diciembre)
Guía Práctica de Optimización de Código de Acceso a Datos en .NET Framework (dictado por Adolfo Wiernik el 6 de diciembre)

Hemos habilitado solamente 20 cupos por curso por ahora.

Para inscribirse: http://learning.solidq.com/la/

Mes de Mejoras de Desempeño en MSDN por Solid Quality Mentors

cwalzer — Thu, 18 Oct 2007 15:04:00 GMT

En el transcurso de este mes los mentores de Solid Quality Mentors hemos difundido nuestros conocimientos en MSDN Latino América, acerca de las técnicas disponibles para Mejora de Desempeño de aplicaciones Microsoft.

Aquí podrás encontrar la información del wecast que dí, el mismo está en línea para que lo puedas ver a demanda:
Herramientas para mejorar el desempeño de las aplicaciones .NET Framework

Material relacionado con este webcast:

Aquí podrás consultar las otras presentaciones relacionadas con este tema:

¿Hablamos del rendimiento de las aplicaciones? por Daniel Seara
Measuring Performance in ASP.NET Applications por Eugenio Serrano
Techniques for Performance Tuning ADO.NET Data Access Code por Adolfo Wiernik

Y como el mes no terminó, aún queda más material por venir

Solid Quality Summit 2007 Chile/Argentina/Brasil

cwalzer — Tue, 16 Oct 2007 18:40:00 GMT

Se está llevando a cabo durante el año 2007 una gira por 9 países visitando 10 ciudades. Es una oportunidad única donde usted podrá escuchar y aprender de los mejores exponentes en Microsoft® SQL Server™ 2005. Contenidos: - Almacenando datos no estructurados o semi-estructurados - Reportes a la carta con el Report Builder - Optimización y Afinamiento de servidores SQL Server - OLAP sin Datawarehouse en SQL Server 2005 Inscríbete ya aqui: http://learning.solidq.com/la/CourseDetail.aspx?CourseScheduleId=208

Anti Prácticas .NET: Lectura de Datos con ADO.NET

cwalzer — Mon, 24 Sep 2007 21:30:00 GMT

Estoy inaugurando sección en mi Blog, con la intención de demostrar el costo que implica una mala codificación o error de diseño en una aplicación .NET. Conversando sobre el tema con Adolfo Wiernik me sugirió el nombre "Anti Prácticas .NET". Seguramente en cada una de estas entregas, intentaré confirmar o desmentir alguna de las leyendas urbanas respecto de .NET, lo cual tendremos merodeando por aquí al "Cazador de Mitos .NET".

En esta primera entrega quisiera demostrar cuál es el costo al momento de seleccionar la forma de leer datos con ADO.NET.Habremos escuchado infinidad de veces decir: Un "DataReader es más rápido que un DataSet", o que "el DataTable es más liviano que el DataSet".

Pues vamos entonces a la caza del mito: "El DataReader es el método más eficiente de lectura de datos".

La intención de este artículo es cuantificar el uso de una u otra forma de acceder a los datos. ¿Ahora bien, porque nos interesaría conocer esto? ¿Qué tienen que ver estos resultados con mi aplicación? ¿Cuándo debo prestarle atención al desempeño de mi aplicación? ¿Porque es tan importante hacerlo? Te recomiendo la lectura del Blog de Daniel Seara.

Presentación del Escenario

Este es el contexto en el que estoy haciendo las mediciones:

Una aplicación ASP.NET 2.0, que utiliza 3 mecanismos para recuperar datos "de solo lectura" de la base de datos AdvertureWorks alojada en SQL Server 2005:

DataReader
DataSet
DataTable

Aquí subrayo "solo lectura" porque, justamente solo quiero mostrar los datos.

El Código

La versión completa del código podrás bajarla de aquí. De todas formas démosle un vistazo:

Hay una clase DataAccess que ejecuta la misma consulta y que devuelve el resultado en 3 formatos distintos: DataSet, DataReader o DataTable.

public class DataAccess
{
    static readonly string _connString;
    static readonly string _sqlCmd;
    static DataAccess()
    {
        _connString = "Password=permiso;User ID=sa;Initial Catalog=AdventureWorks;Data Source=WALZER3";
        _sqlCmd = "SELECT HumanResources.Employee.EmployeeID, Person.Contact.FirstName, " +
       "Person.Contact.MiddleName, Person.Contact.LastName, " +
       "HumanResources.Employee.Title, HumanResources.Employee.BirthDate, " +
        "Person.Address.AddressLine1, Person.Address.AddressLine2, " +
        "Person.Address.City, Person.Address.PostalCode, Person.Contact.EmailAddress, " +
        "Person.Contact.Phone, HumanResources.Employee.MaritalStatus, HumanResources.Employee.Gender " +
        "FROM HumanResources.Employee INNER JOIN " +
        "Person.Contact ON HumanResources.Employee.ContactID = Person.Contact.ContactID INNER JOIN " +
        "HumanResources.EmployeeAddress ON " +
        "HumanResources.Employee.EmployeeID = HumanResources.EmployeeAddress.EmployeeID INNER JOIN " +
        "Person.Address ON HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID AND " +
        "HumanResources.EmployeeAddress.AddressID = Person.Address.AddressID";
    }

    static public DataSet TraerDataSet()
    {
        DataSet ds = null;
        try
        {
            using (SqlConnection conn = new SqlConnection(_connString))
            {
                conn.Open();
                SqlCommand cmd = new SqlCommand();
                cmd.CommandText = _sqlCmd;
                cmd.Connection = conn;
                cmd.CommandType = CommandType.Text;
                SqlDataAdapter da = new SqlDataAdapter(cmd);
                ds = new DataSet();
                da.Fill(ds);
            }
        }
        catch
        {
        }
        return ds;
    }

    static public IDataReader TraerDataReader()
    {
        SqlDataReader dr = null; SqlConnection conn = null;
        try
        {
            conn = new SqlConnection(_connString);
            conn.Open();
            SqlCommand cmd = new SqlCommand();
            cmd.CommandText = _sqlCmd;
            cmd.Connection = conn;
            cmd.CommandType = CommandType.Text;
            dr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
        }
        catch
       {
            if (conn != null)
                conn.Close();
            throw;
        }
        return dr;
    }

    static public DataTable TraerDataTable()
    {
        DataTable dt = null;
        try
        {
            using (SqlConnection conn = new SqlConnection(_connString))
            {
                conn.Open();SqlCommand cmd = new SqlCommand();
                cmd.CommandText = _sqlCmd;
                cmd.Connection = conn;cmd.CommandType = CommandType.Text;
                using (SqlDataReader dr = cmd.ExecuteReader())
                {
                    dt = new DataTable();
                    dt.Load(dr);
                }
            }
        }
        catch
        {
        }
        return dt;
    }
}

Luego hay 3 páginas aspx que muestran los datos obtenidos enlazando los datos con un DataRepeater:

<asp:Repeater ID="dataReapeater" runat="server">
    <HeaderTemplate>
        <table border="1">
            <tr bgcolor="crimson">
                <th>EmployeeID</th>
                <th>First Name</th>
                <th>Middle Name</th>
                <th>Last Name</th>
                <th>Title</th>
                <th>Birthdate</th>
                <th>Adress Line 1</th>
                <th>Adress Line 2</th>
                <th>City</th>
                <th>Zip</th>
                <th>Email</th>
                <th>Phone</th>
                <th>MaritalStatus</th>
                <th>Gender</th>
           </tr>
           </HeaderTemplate>
                <ItemTemplate>
                    <tr>
                        <td><%# DataBinder.Eval(Container.DataItem, "EmployeeId") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "FirstName") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "MiddleName") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "LastName") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "Title") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "Birthdate") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "AddressLine1") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "AddressLine2")%></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "City") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "PostalCode") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "EmailAddress") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "Phone") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "MaritalStatus") %></td>
                        <td><%# DataBinder.Eval(Container.DataItem, "Gender") %></td>
                    </tr>
                </ItemTemplate>
            <FooterTemplate>
       </table>
    </FooterTemplate>
</asp:Repeater>

Y este es el código correspondiente al PageLoad de cada página aspx:

TraerDataSet.aspx

public partial class TraerDataSet : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        MostrarDataSet();
    }

    private void MostrarDataSet()
    {
        dataReapeater.DataSource = DataAccess.TraerDataSet().Tables[0];
        dataReapeater.DataBind();
    }

}

TraerDataReader.aspx

public partial class TraerDataReader : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        MostrarDataReader();
    }

    private void MostrarDataReader()
    {
        using (IDataReader dr = DataAccess.TraerDataReader())
        {
            dataReapeater.DataSource = dr;
            dataReapeater.DataBind();
        }
    }
}

TraerDataTable.aspx

public partial class TraerDataTable : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        MostrarDataTable();
    }

    private void MostrarDataTable()
    {
        dataReapeater.DataSource = DataAccess.TraerDataTable();
        dataReapeater.DataBind();
    }
}

Como verás la prueba es sencilla y el código está centrado en la recuperación de los datos, y no en la forma en que esos datos se muestran. Claro que es una parte muy importante también, para conocer cómo hacerlo en ASP.NET te recomiendo el Blog de Eugenio Serrano.

Primeras Lecturas

Lo que primero vamos a medir es el tiempo que se toma cada una estas operaciones para mostrar los datos. Para ello utilicé la herramienta JetBrains DotTrace 3.0. Esta herramienta te permite mediante la técnica de "code profiling" conocer el tiempo y cantidad de veces de cada una de las llamadas a los métodos de tu aplicación, incluido el código de .NET.

Observemos entonces el tiempo consumido durante 5 llamadas de cada una de los métodos que acceden y muestran los datos. A propósito, la consulta devuelve 232 registros.

Mirando los recuadros rojos podremos observar que recuperar los datos con DataReader es lo más rápido: 24% más rápido que hacerlo con DataSet y 33% más rápido que con DataTable.

Sin embargo si miramos los números de la clase DataAccess (recuadro verde), no guardan relación con la vista anterior. El método TraerDataReader consume un tiempo irrisorio frente a los otros. Como bien me apuntó Javier Loría, hasta ese momento (en el cual el DataReader es devuelto por el método), solo hemos abierto la conexión con las base de datos y enviado el comando sql, y hasta tanto no hayamos mostrado los datos, el cursor no se ha movido del BOF. Distinto es el caso del TraerDataSet o el TraerDataTable, en el cual, para poder pasarse entre capas levantan los datos de la base de datos y se desconectan.

Con lo cual podemos sacar 2 conclusiones:

El DataReader no es un objeto para pasar entre capas.
Si solo queremos mostrar los datos con el DataSet o el DataTable, los habremos recorridos 2 veces, una vez para cargarlos en memoria y la segunda para mostrarlos.

Claro que no siempre podemos decidir solo en función del mejor desempeño. ¿Cuál es la forma apropiada de utilizar ADO.NET en una capa de acceso a datos?, lo puedes leer en el Blog de Adolfo Wiernik.

¡Mito cazado! El DataReader es el método más eficiente de lectura de datos.

Pero lo del DataTable no tiene una explicación muy lógica. Recuperar el DataTable, en este caso, es 2 veces más lento que el DataSet. Pongámonos a investigarlo.
Miremos ahora el enlace a los datos:

Esta vista muestra el tiempo consumido por el método System.Web.UI.WebControls.Repeater.DataBind() y quien lo ha invocado. Si observamos veremos que los tiempos son similares, las diferencias son despreciables. Aquí no está la diferencia...

Estudio interno de las formas de acceso a los datos

Veamos ahora como se consume el tiempo en cada uno de nuestros métodos de acceso a datos:

MostrarDataReader()

En esta vista podemos observar el tiempo de las invocaciones realizadas dentro el método y el tiempo consumido por cada una de ellas.
El 97% del tiempo lo ha consumido System.Web.UI.WebControls.Repeater.DataBind(), o sea recorrer los datos con el cursor de solo lectura y avance y mostrarlos. El resto se va en System.Data.SqlClient.SqlCommand.ExecuteReader(), que comprende la apertura de la conexión y el envío del comando a la base de datos.

MostrarDataSet()

Observemos ahora el método que devuelve el DataSet, que nos servirá para entender cómo trabaja ADO.NET por dentro.

En el recuadro verde está resaltado System.Data.Common.DataAdapter.Fill(), método privado de la clase DataAdapter que realiza básicamente 2 tareas: leer los datos y cargarlos en la colección de DataTables del DataSet.
¿Como los lee?, mediante System.Data.Common.DbCommand.ExecuteReader() (recuadro rojo). Sí, internamente utiliza un cursor de solo lectura y avance (DataReader) para recuperar los datos. Y de paso vale la pena destacar que esa llamada consumió lo mismo (87 ms) que la llamada realizada en TraerDataReader() (87 ms). Entonces, ¿donde está la diferencia en tiempo?, en el método System.Data.Common.DataAdapter.FillFromReader() que consumió 1164 ms. Este método es el que se encarga de cargar los datos en memoria (DataSet).

El recuadro azul viene a colación del estudio que hagamos de TraerDataTable(), que si recuerdas tardaba el doble que TraerDataSet().

MostrarDataTable()

Trataremos de develar la incógnita de porque, si aparentemente no debería haber diferencia en cargar un DataTable y un DataSet, el primero es 2 veces más lento que el segundo, cuando de hecho un DataSet contiene una colección de DataTable.

Antes que nada veamos que System.Data.Common.DbCommand.ExecuteReader() (recuadro rojo) es el mecanismo interno nuevamente utilizado para recuperar los datos, cuya llamada consumió 82 ms al igual que antes. También encontramos el mismo método System.Data.Common.DataAdapter.FillFromReader() (recuadro azul), pero que esta vez consumió 2986 ms, casi el triple del tiempo que en el caso del DataSet. Si revisamos las invocaciones realizadas por FillFromReader() vemos que System.Data.Common.DataAdapter.FillLoadDataRow() está presente con el mismo tiempo consumido (1157 ms) en la carga del DataSet y el DataTable. La gran diferencia está en las llamadas internas que realiza System.Data.DataTable.EndLoadData() (1607 ms), que como su nombre lo sugiere, realiza unas operaciones luego de que los datos ya están memoria. Veamos de que operaciones estamos hablando (para ello utilicé la herramienta Reflector que permite desensamblar el código .NET):

public void EndLoadData()
{
    IntPtr ptr;
    Bid.ScopeEnter(out ptr, "<ds.DataTable.EndLoadData|API> %d#\n", this.ObjectID);
    try
    {
        if (this.inDataLoad)
        {
            if (this.loadIndex != null)
            {
                this.loadIndex.RemoveRef();
            }
            if (this.loadIndexwithOriginalAdded != null)
            {
                this.loadIndexwithOriginalAdded.RemoveRef();
            }
            if (this.loadIndexwithCurrentDeleted != null)
            {
                this.loadIndexwithCurrentDeleted.RemoveRef();
            }
            this.loadIndex = null;
             this.loadIndexwithOriginalAdded = null;
            this.loadIndexwithCurrentDeleted = null;
             this.inDataLoad = false; this.RestoreIndexEvents(false);
             if (this.DataSet != null)
           {
                 this.DataSet.EnforceConstraints = this.savedEnforceConstraints;
             }
             else
             {
                 this.EnforceConstraints = true;
             }
        }
    }
    finally { Bid.ScopeLeave(ref ptr); }
}

Analizando esta sección del código:

            if (this.DataSet != null)
            {
                this.DataSet.EnforceConstraints = this.savedEnforceConstraints;
            }
            else
            {
                this.EnforceConstraints = true;
            }

vemos que si el objeto DataTable forma parte de un DataSet (this.DataSet) se verifican las restricciones (constraints) si es que la variable privada this.savedEnforceConstraints así lo indica, y sin embargo si el DataTable es un objeto aislado (standalone) que no depende de un DataSet las restricciones se verifican siempre. Es así que cuando se asigna true a this.DataSet.EnforceConstraints, se realiza el proceso de verificación de las restricciones. Volviendo al gráfico podrás ver las llamadas a System.Data.DataTable.set_EnforceConstrains y las invocaciones internas a System.Data.DataColumn.IsNotAllowDbNullViolated() y System.Data.DataColumn.IsMaxLengthViolated() que ambas consumen el 52% del tiempo total.

La página VerPropiedadesColumnas.aspx del ejemplo nos da un indicio. Esta nos muestra las propiedades de los DataColumns del DataSet y del DataTable.
Allí observamos que la propiedad AllowDbNull está marcada según las propiedades de la tabla en la base de datos solo para el DataTable.

De ahí se explica entonces las llamadas a System.Data.DataColumn.IsNotAllowDbNullViolated() por ejemplo:

internal void EnableConstraints()
{
    IntPtr ptr;
    Bid.ScopeEnter(out ptr, "<ds.DataSet.EnableConstraints|INFO> %d#\n", this.ObjectID);
    try
    {
        bool flag = false;
        ConstraintEnumerator enumerator3 = new ConstraintEnumerator(this);
        while (enumerator3.GetNext())
        {
            Constraint constraint = enumerator3.GetConstraint();
           flag |= constraint.IsConstraintViolated();
       }
       foreach (DataTable table in this.Tables)
       {
           foreach (DataColumn column in table.Columns)
           {
               if (!column.AllowDBNull)
               {
                   flag |= column.IsNotAllowDBNullViolated();
                }
                if (column.MaxLength >= 0)
               {
                    flag |= column.IsMaxLengthViolated();
               }
            }
        }
         if (flag)
        {
             this.FailedEnableConstraints();
        }
     }
     finally { Bid.ScopeLeave(ref ptr);
    }
}

Ahora que conocemos que es lo que realmente sucede tratemos de encontrar una explicación lógica de porque se verifican las restricciones en el caso del
DataTable aislado y no así en el DataSet. La respuesta está documentada:

El método DataAdapter.Fill no establece todas las propiedades de los objetos DataTable y DataColumn

Síntomas

Después de que utiliza el método DataAdapter.Fill, no se establecen varias propiedades del DataTable y objetos DataColumn (como clave principal, campos automáticos de incremento, campos anulables, índice único y etc.)

Causa

El objeto DataAdapter está optimizado para sólo lectura de manera predeterminada. El método Fill sólo recupera la cantidad de esquema que es necesario mostrar los datos. Debe seguir pasos adicionales que obtienen el esquema adicional que es necesario actualizar o validar un objeto.

Solución

Para obtener información adicional acerca del objeto DataSet, utilice uno de los métodos siguientes:

Llame al método DataAdapter.FillSchema para obtener información de esquema ampliado.
Establezca el valor de DataAdapter.MissingSchemaAction a MissingSchemaAction.AddWithKey antes de llamar al método Fill

Optimización de lectura de datos con DataTable

Pues hagamos caso de lo que el artículo dice: el que está optimizado para lectura de datos es el método DataAdapter.Fill(). Veamos que sucede si cargamos el DataTable con este mecanismo.

static

public DataTable TraerDataTableOptimizado()
{
    //Este método está optimizado para cargar un DataTable con datos de SOLO LECTURA
    DataTable dt = null;
    try
    {
        using (SqlConnection conn = new SqlConnection(_connString))
       {
         conn.Open();
         SqlCommand cmd = new SqlCommand();
          cmd.CommandText = _sqlCmd;
          cmd.Connection = conn;
          cmd.CommandType = CommandType.Text;
          SqlDataAdapter da = new SqlDataAdapter(cmd);
          dt = new DataTable();
          da.Fill(dt);
       }
    }
    catch
    {
    }
    return dt;
}

¡Ahora sí! el tiempo consumido por la recuperación del DataTable se asemeja al del DataSet.

Ahora que ya sabes interpretar los informes del profiler de código, revisa las llamadas internas de TraerDataTableOptimizado().

Podrás apreciar que las llamadas a EndLoadData bajaron del 1607 ms a 0.4. Y este número podría haber sido más grande si la cantidad de datos registros y columnas fuese mayor.

Conclusión

Hemos comprobado que el uso correcto de las técnicas de acceso a datos en ADO.NET nos permite lograr un mayor rendimiento en nuestras aplicaciones. También hemos aprendido algo de cómo funciona internamente ADO.NET, ejercicio que nos va a servir para tomar buenas decisiones al momento de elegir nuestra estrategia de acceso a datos.

Continuación

Parte II
Parte III

Webcast: Herramientas para mejorar el desempeño de las aplicaciones .NET Framework

cwalzer — Thu, 20 Sep 2007 21:58:00 GMT

Los invito a escuchar este webcast que daré el Viernes 5 de Octubre 2007.

Daremos una recorrida por las herramientas que propone Microsoft para Detectar y Diagnosticar problemas de desempeño y mal uso de la memoria de aplicaciones .NET: Visual Studio 2005 Team System para hacer pruebas de carga y stress sobre sitios ASP.NET. CLR Profiler y Visual Studio 2005 Team System para hacer profiling de código y de memoria. Fiddler para hacer debugging de HTTP. Todas ellas, en conjunto, son de gran ayuda al momento de mejorar el desempeño de nuestras aplicaciones.

Registrarse

El debugging es solo para eso: Depuración

cwalzer — Tue, 11 Sep 2007 16:06:00 GMT

Para confirmar lo que mi amigo Patrick MacKay explica en estos 3 artículos:
¿Por qué debo definir "debug=false" en web.config?, Parte I
¿Por qué debo definir "debug=false" en web.config?, Parte II
¿Por qué no debo compilar en modo debug?, Parte III
,quisiera mostrarles los resultados de la ejecución de test de stress sobre un sitio ASP.NET compilado en modo debug.

Me topé con un caso en el cual el sitio había sido compilado en modo debug y habilitado debug=true en el web.config . Claro no me enteré de esto hasta que me dijeron: "Pusimos a correr la prueba y no anduvo, hay un valor % Time in Jit que está muy alto". Y efectivamente estaba muy alto:

Noten que el contador % Time in Jit de la categoría .NET CLR JIT se mantiene constante durante 3 horas a valores altísimos. Los umbrales propuestos por Visual Studio 2005 para este contador son:
Warning: 25
Critical: 50
Según mi experiencia en una prueba de stress, salvo el primer minuto donde hay picos de hasta 80%, el valor normal no supera el 1%.
Si se fijan la cantidad de Requests/seg que la aplicación logró responder es 0. La aplicación Web está totalmente inhibida.

Una segunda corrida mas corta tratando de encontrar el problema arrojó el mismo resultado:

Estas mediciones confirman lo tratado en el artículo I, donde Patrick muestra como se sucede la compilación de un sitio ASP.NET al hacerse una petición. Excelente tratamiento de parte de Patrick al tema.

El debugging es solo para eso: depuración.