Carlos Walzer : Cazador de Mitos .NET

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

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