Rendimiento: LinQ to SQL vs DataReader
Estaba yo conversando con un compañero de trabajo y hablando sobre LinQ y saltó la pregunta, que tan rápido puede ser LinQ to SQL en la selección de registros en comparación con la extracción de registros de un DataReader… y como una duda de ese tipo no puede quedar en el olvido, decidí que sería interesante hacer una comparación en cuanto a la velocidad en la selección de registros.
Pues bien, para este ejemplo utilicé la mundialmente famosa base de datos Northwind de SQL Server y una aplicación de consola que extraía los campos OrderId y CustomerId de la tabla Orders, para agregarlos a un StringBuilder. Claro, no tiene sentido que agregue los datos en el StringBuilder, pero lo que me interesaba a mi, era tomar el tiempo que tomaba en extraer los datos y recorrer todos los registros. Como ven en la siguiente imágen, el tiempo que le ha tomado a LinQ to SQL hacer la misma operación que ha un DataReader es ligeramente menor que al DataReader.
Ahora, para esto hay que tener algunas cosideraciones; como ya es sabido por todos, LinQ to SQL hace un mapeo de las tablas de la BD y crea las clases con propiedades que representan cada campo de la tabla, si yo cargo todos los campos incluyendo los que no voy a utilizar, obviamente el peso de los objetos será mayor y el rendimiento no será el mismo, de manera que lo que hice fue solo tomar las propiedades (campos de la tabla) que voy a utilizar, lo mismo que haría en un procedimiento almacenado que extrae datos, si voy a utilizar 2 campos no tengo porque extraer más que eso:
Ahora, el código que utilicé para extraer los datos es el que me parece que me proporciona un mejor rendimiento, aunque claro, como LinQ to SQL es algo nuevo, he de asumir que podría mejorarse. El código para extraer los datos vía DataReader se ve a continuación:
Como se puede ver, utilizo la instrucción using para asegurarme de liberar recursos al terminar de utilizar los oobjetos y al abrir el Reader utilizo CommandBehavior CloseConnection (para cerrar la conexión en cuanto se cierre el reader) y SingleResult (para indicarle al reader que el Procedimiento Almacenado solo devuelve un conjunto de resultados y no más (osea, un solo select). En tanto que para el código del trabajo con LinQ he utilizado también using y el proceso normal de trabajo con LinQ, como se ve en la imágen:
En resúmen, el rendimiento de LinQ to SQL es aceptable en un primer momento con esta mini prueba sencilla, la mejora como ya se ha comentado en tantos lugares de la red consiste en la posibilidad de trabajar con un código sencillo y mapear la base de datos reduciendo el tiempo en el desarrollo de código que ofrece LinQ. Aunque en realidad, cada uno debe hacer pruebas de rendimiento para considerar si se ajusta o no al caso que esta siendo tratado.
Espero que esta info les sea de utilidad.
Saludos.
Leave a Reply