Imagen de Maitree Rimthong en Pexel

Últimamente veo muncho benchmark que si usa el span<T>, que, si usa struct, que es mejor usar esto y lo otro o charlas muy similares, pero nunca nos paramos a pensar en estos dos olvidados. Seguro que, si te pregunto rápidamente que diferencia existe entre ref y var, me la dices, pero no sabes que implicación tiene en tu proyecto a nivel de optimización.

Y nunca, se cuenta que usar la cláusa ref es una optimización.

Por qué lo estoy haciendo mal:

Muy sencillo, por que es más fácil no poner esa cláusula, siempre nos olvidamos y, por tanto, inconscientemente estamos trabajado con el valor real que puede ser modificado (ver documentación oficial), algo que es un peligro a efectos de desarrollo.

Para muestra el ejemplo más simple del mundo:

En esta primera y segunda captura os muestro el código que puedes descargar desde Github.

Y en esta el resultado del test:

Como puedes observar pasar una variable por referencia es más barato que por valor.

En el ejemplo son millones de ejecuciones con algo muy muy sencillo, al final solo ganas algo menos de 10ms, pero cuando la manipulación es alta, al final llegará a perder segundos y al final de año minutos… puede que sea despreciable, pero lo que no lo es cuando tienes un sistema de alta demanda y tienes que optimizar.

Además que estás poniendo en peligro tu aplicación con errores que son costosos de detectar, por fortuna estas haciendo test y no ocurrirá wink

Conclusión:

Con este ejemplo os he querido poner en aviso que cuando hables de optimización, debes empezar por lo más básico, que es esto. Una frase como:

Inconscientemente casi seguro que has empezado a “optimizar” al usar cosa chulas de .NET , pero que sepas que estás haciendo cosas mal desde el principio. Ya que en parte está poniendo en peligro la aplicación y además estas pagando eso con ms extras.

En resumen: debes ser consciente que estás realizando de forma inconsciente una mala optimización de tu aplicación por no ir a la base, además de meter un posible error que siempre es complicado localizar, debes seguir la pista a tu proceso para dar donde se está modificando incorrectamente.

Como se suele decir en fotografía: conoce la regla de los tres tercios antes de romperla. Extrapólalo aquí, conoce las bases antes de ir más allá.