La estructura ValueTask

“… ‘Cause I’ve been here, and I’ve been there,
Seems like I’ve been everywhere before.
I’ve seen it all a hundred times
Still I think there surely must be more…”
Kansas, “Paradox” (1977)

Repasando la enorme cantidad de características añadidas a  C# en las versiones 6 y 7.x, realmente puede dar la impresión de que (como dice la referencia musical de hoy) no queda nada más que inventar. Sin embargo, ya tenemos casi a la vuelta de la esquina a C# 8.0, con una buena cantidad de novedades relevantes.

Buscando entre las características incorporadas a partir de la versión 7.0 de las que no he hablado aún aquí (y que no sean totalmente triviales, como por ejemplo las mejoras en la representación de constantes numéricas), encontré la generalización de los tipos de retorno de los métodos asíncronos (generalized async return types), una característica que ha cobrado importancia principalmente debido a la aparición de un nuevo tipo que se ha hecho posible gracias a ella, ValueTask<T>,  que hace posible mejorar el rendimiento en ciertos escenarios de utilización de llamadas asíncronas.

Como seguramente sabrá, antes de C# 7.0 los métodos asíncronos solo podían devolver los tipos Task<TResult> (si se retorna un valor), Task (si el método realiza una acción y no retorna ningún valor) o void (en el caso de los gestores de eventos asíncronos1). A partir de  C# 7.0, se permite también que un método asíncrono devuelva un objeto de cualquier tipo que ofrezca un método GetAwaiter que a su vez retorne un objeto que implemente la interfaz ICriticalNotifyCompletion (espacio System.Runtime.CompilerServices). Lo más apropiado para esta entrada sería crear precisamente un tipo así, pero tengo la impresión de que eso tendría un interés puramente académico: no he encontrado en la web ninguna referencia a un tipo similar creado por terceros. Da la impresión de que esta generalización se ha hecho con el objetivo específico de abrir las puertas a la definición de ValueTask<T>, que precisamente cumple con ese requisito y que además tiene otra característica esencial: no es un tipo por referencia (class) sino un tipo por valor (struct). Es este hecho el que hace posible una mejora del rendimiento en ciertos escenarios de uso de los métodos asíncronos, como describiremos a continuación.

Para el ejemplo de hoy utilizaré la peor manera posible (o la más ingenua, si queremos ser más políticamente correctos) de implementar el cálculo del n-simo elemento de la serie de Fibonacci, en la que cada elemento subsiguiente de la serie se obtiene sumando los dos anteriores a él. Y como siempre es posible empeorar aún más algo que ya está mal, he añadido una “guinda al pastel” haciendo la que las llamadas recursivas se realicen de manera asíncrona. Esta variante asíncrona es la que me servirá como base para mostrar cómo el uso de ValueTask mejora el rendimiento (¿le parece a usted, querido lector, que el fin siempre justifique los medios? ;-)). Eche un vistazo al siguiente código:

using System;
using System.Threading.Tasks;

namespace Fibo
{
    class MainClass
    {
        static void Main(string[] args)
        {
            TimeMethod(() => { Console.WriteLine(Fibo(40)); } );
            TimeMethod(() => { Console.WriteLine(FiboAsync(40).Result ); } );
        }

        static long Fibo(int n)
        {
            if (n <= 1)
                return 1;

            return Fibo(n - 2) + Fibo(n - 1);
        }

        static async Task<long> FiboAsync(int n)
        {
            if (n <= 1)
                return 1;

            return await FiboAsync(n - 2) + await FiboAsync(n - 1);
        }

        static void TimeMethod(Action action)
        {
            DateTime t1 = DateTime.Now;
            action();
            DateTime t2 = DateTime.Now;
            Console.WriteLine("Ellapsed " +
                (t2 - t1).TotalMilliseconds + " ms.");
        }
    }
}

La salida que produce el programa anterior es la siguiente:

165580141
Ellapsed 1612.459 ms.
165580141
Ellapsed 44734.77 ms.

Así que introduciendo la asincronía sin que hubiera necesidad alguna hemos hecho el código unas 27 veces más lento :-). Pero esta entrada no intenta predicar sobre en qué situaciones se deben utilizar los métodos asíncronos; este enlace podría ser un buen comienzo para ello. Aquí yo solo intentaba buscar un ejemplo en el que el uso de ValueTask<T> ofreciera una mejora en rendimiento sobre Task<T>, y me pareció que éste podría ser un buen caso, porque en él se realiza una gran cantidad de cálculos repetidos, y cada invocación recursiva termina provocando llamadas a los casos base, en los que el resultado (1) está predeterminado.

Para poder hacer uso de la estructura ValueTask<T>, hace falta importar de Nuget el paquete System.Threading.Tasks.Extensions:

Ahora, sustituyendo la única referencia a Task en el código fuente por ValueTask y ejecutando, se obtiene como promedio lo siguiente:

165580141
Ellapsed 1617.608 ms.
165580141
Ellapsed 39123.887 ms.

La ganancia no es tanta como yo esperaba, pero en cualquier caso un 13% de mejora en el rendimiento no es nada despreciable.

La razón por la que el rendimiento es superior al utilizar ValueTask estriba en que cuando se utiliza el tipo Task, que es una clase, es necesario cumplir con el protocolo de instanciación de un objeto incluso en los casos base, para los que el resultado está predeterminado de antemano y en principio no haría falta ninguna tarea (retornando la llamada de forma síncrona). Al ser ValueTask un tipo por valor, la tarea a devolver se aloja en la pila, evitando así la costosa instanciación en todos esos casos base.

Note que también el uso de ValueTask hace posible una menor presión sobre la memoria (memory pressure), y una disminución en la frecuencia entre ejecuciones del recolector de basura (garbage collector). Este vídeo de Andrea Angella ilustra fenomenalmente este beneficio.


1 Frecuentemente encontrará recomendaciones sobre no crear métodos async void, como ésta de Bill Wagner.

Referencia musical: “Paradox” pertenece al “Point of Know Return” (1977), que es mi disco favorito de mi banda favorita, Kansas, a pesar de que la critica generalmente considera superior al proyecto anterior, “Leftoverture” (1976) – vea por ejemplo este reportaje de Rolling Stone que lo coloca en el lugar 32 de los mejores álbumes de rock progresivo de todos los tiempos.

Octavio Hernandez

Desarrollador y consultor en tecnologías .NET. Microsoft C# MVP entre 2004 y 2010.

Deja un comentario

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