EF 4.0 Performance Tips #5 (#1 Revisited )

El el primer tip de rendimiento sobre EF 4.0, #1, hablamos sobre las diferencias que se producían si en nuestras consultas sobre L2E hardcodeábamos valores o hacíamos uso de variables. Básicamente mientras el uso de variables provocaba que las consultas fueran parametrizadas el hecho de establecer valores directamente  hacía que nuestras consultas fueran adhoc y por lo tanto un trashing de nuestra cache de planes de ejecución.

Este comportamiento es lo normal y la recomendación es nunca hardcodear valores, aunque hay cierto tipo de consultas que no se comportan como quizás deberían y aunque sigamos las recomendaciones podremos observar alguna consulta AdHoc. La que yo conozco, eso no quita que pueda existir algún caso más tiene que ver con el uso de los métodos extensores SKIP y TAKE de L2E, los cuales por alguna razón, que la sé y no me convence para nada, ‘funcletizan’ los valores y eliminan la posiblidad de hacer las consultas parametrizadas.

 

Vamos a la práctica y pongamos las siguientes lineas de código:

 

 

Ámbos métodos obtienen una colección de Customer de forma paginada y hacen uso de variables para indicar los parámetros de paginación. Según lo expuesto por mi en el tip #1 la consulta en L2E debería de ser parametrizada ¿verdad?. Pues veamos los resultados haciendo una consulta sobre la vista administrada que nos da los elementos almacenados en la cache de planes de ejecución de Sql Server.

 

Untitled

Como se puede observar, la fila 2 que se corresponde en este caso a la consulta en ESQL ha parametrizado la misma, mientras que la consulta 3, L2E, es una consulta AdHoc.

 

Bien, ya hemos expuesto el problema, ahora toca hablar de las soluciones. Lógicamente ya hemos expuesto una de ellas, sustituir las consultas que usan paginación escritas en L2E por consultas que usen ESQL, dentro de poco trataré de enseñar como construir un método extensor que nos ayude en esta tarea. Otra de las posibles soluciones es tratar de “confiar” en el mecanismo de auto parametrización de Sql Server, aunque esto no se si sería demasiado realista.  Para terminar, el tercer workaround, para intentar solventar este problema sería hacer uso de CompiledQuery tal y como vemos a continuación.

 

 

Si examinamos ahora los planes de ejecución veremos como ahora, ambas consultas son parametrizadas.

Untitled2

Saludos

Unai

3 comentarios sobre “EF 4.0 Performance Tips #5 (#1 Revisited )”

  1. Muy interesante …
    aunque no son la misma consulta: en la consulta L2E utilizas Take y realizas un OrderBy previo, mientras que en la consulta de ESQL y usas Top y no haces ordenacion.

    ¿se comportaria igual la consulta de ESQL usando Take?

    Saludos,
    Pedro

  2. Perdona Pedro, pero estas equivocado, SON exáctamente la misma consulta. En primer lugar el método Take no está en ESQL como método de construcción de consultas, su sinónimo es TOP, en segundo lugar claro que se ordena, si te fijas el método de construcción skip te obliga a indicar la ordenación, en este caso it.CustomerCode, que es exáctamente por lo que se ordena tb en L2E, por lo tanto creo que tu pregunta está respondida

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *