Imagen de Maitree Rimthong en Pexel

Muchas veces me toca explicar que ciertas cosas en .NET concretamente en C# donde han de tener cuidado. Por ejemplo, una de ellas es la cache in-memory u otras cosas como sealed. Para que veáis con datos que está en nuestra mano como devs poder aportar mejoras sustanciales a nuestras aplicaciones que millones de peticiones. No todo se trata de poner lo más caro y potente.

Un ejemplo para que se vea como afecta el uso de Sealed a tu aplicación:

Lo primero es que revises la documentación oficial: Sealed. Continua con el artículo cuando lo tengas asimilado.

Evitar que una clase heredada por otra clase con Sealed nos permite obtener un aumento significativo del rendimiento de la aplicaicón.

Al sellar la calse, el compilador JIT puede conocer directamente el tipo de datos real del objeto. Por contra, aquellas que no están selladas obligan a JIT a verificar si la case tiene o no subclases.

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

Y en esta el resultado del test. Es obvio el resultado:

 Como verás en ningún momento Microsoft en su documentación no habla de esta gran ventaja que os he mostrado con datos.

Por tanto:

En tus Web App, en tus Functions, en Jobs, etc. etc. que despliegues en Azure y cualquier cloud.

Es un punto a tener en cuenta, ya que subir al coste de ms en vez de ns, al final de año es un gasto innecesario.

Mi recomendación es que cuando alguien del equipo se dedide a refactorizar debe ser alguien con un nivel técnico muy alto que sepa identificar este tipo de cosas.

Y si alguien no te cree:

Usa la librería de Benchmark para realizar una demostración irrefutable.

Tengo pendiente un artículo con EF, DapprLib y ADO.NET donde se muestra la velocidad de trabajo con una u otra librería.