struct – Quantum Insights

Para ver algo más de las nuevas posibilidades de las estructuras de C#, voy a mostrar una clase sencilla que utilizo en Iridium, un motor de valoración de swaps, en su versión nativa para .NET Core. La estructura (¡qué sorpresa!) sirve para representar fechas pero, a diferencia de DateTime, sin la parte de la hora.

Internamente, una fecha se representa como el número de días transcurridos desde el uno de enero del año 1. Como son fechas para software financiero, me la trae al viento los problemas de cambio de calendario. Con estas premisas, puedo representar el número de días con un valor entero de 32 bits, con lo que mi tipo Date ocupa la mitad del espacio que un DateTime. Esta es la declaración de la estructura y de su único campo de estado:

/// <summary>A date with efficient operations.</summary>
public readonly struct Date : IEquatable<Date>, IComparable<Date>
{
    /// <summary>Number of days since Jan 1st, 1.</summary>
    private readonly int date;
    public Date(int year, int month, int day) { ... }
}

Para ganar velocidad, además, el constructor no verifica que los componentes de una fecha sean correctos: en Iridium, eso es responsabilidad del generador de cupones y otras partes del código que generan fechas.

Ahora viene la parte más interesante del tipo de datos:

public void Deconstruct(
     out int year, out int month, out int day) { ... }

Un deconstructor es un método que permite, precisamente, extraer en una sola operación las partes integrantes de una instancia de un tipo. Se introdujeron pensando en las tuplas, pero en realidad se pueden usar con cualquier clase o estructura, y es una pena que DateTime no cuente con uno de estos métodos. Gracias al deconstructor, podemos ejecutar instrucciones como la siguiente:

var (y1, m1, day1) = fromDate;

Si tuviese que usar DateTime, tendría que llamar por separado a las tres propiedades Year, Month y Day de la fecha. ¿El problema? Pues que para recuperar el año a partir de la representación interna hay que ejecutar un pequeño algoritmo que lleva su tiempo. Si luego quiero el mes, no importa: tengo que volver a ejecutar la parte que extrae el año. Y lo mismo pasa al pedir el día del mes. Con el deconstructor, en cambio, sólo tengo que descomponer la fecha en partes una sola vez, y obtengo los tres componentes. De hecho, la implementación de mi propiedad Day se permite el lujo de usar internamente el deconstructor:

public int Day
{
    get
    {
        Deconstruct(out _, out _, out int d);
        return d;
    }
}

Los subrayados son comodines para descartar el año y el mes.

¿Más cosas que pueden interesar? Por ejemplo, se permiten las conversiones de tipo entre Date y DateTime, en ambos sentidos, y permito convertir un valor Date en un número (la conversión inversa se consigue más elegantemente con un constructor adicional):

public static explicit operator DateTime(Date d) =>
    new DateTime(d.date * TicksPerDay);
public static explicit operator Date(DateTime d) =>
    new Date((int)(d.Ticks / TicksPerDay));
public static explicit operator int(Date d) => d.date;

El código completo de la clase puede descargar desde este enlace.

Hay un antes y un después en C# en lo que atañe a los tipos struct, y tiene que ver con la llegada de RyuJIT, más que con .NET Core. El compilador de código nativo ha aprendido a manejar eficientemente estos tipos de datos.

Todos sabemos que las estructuras se diferencian de las clases en que son tipos con semántica de asignación por valor, en vez de la semántica habitual de asignación por referencia. Una variable de tipo struct contiene directamente los datos, mientras que una variable de clase es realmente un puntero a la zona de memoria donde residen los datos.

Lo quiero explicar en esta entrada, sin embargo, es cuándo es eficiente y aconsejable utilizar un tipo de estructura en vez de un tipo de clase. Hay un par de casos, y el primero de ellos es el más evidente: cuando el espacio que ocupan los campos de la estructura es suficientemente pequeño como caber en un registro de hardware.

Por ejemplo, .NET representa las fechas mediante el tipo de estructura DateTime. Este tipo guarda internamente un campo de tipo long, que representa el número de tics transcurridos desde cierta fecha base. Esto cabe en un registro de 64 bits. Para que todo vaya sobre ruedas, además, la estructura se declara de sólo lectura:

public readonly struct DateTime { }

En realidad, .NET Core es quien declara el tipo de sólo lectura. .NET Framework no lo hace, pero trata el tipo como si lo fuese. El cualificador readonly es relativamente nuevo en C#.

Para entender la utilidad de este caso de uso (disfrazar un tipo de datos numérico) hay que comparar con lo que ocurriría en un lenguaje como Java, que de momento no permite definir tipos de valor. O metes el entero en una clase, y cada vez que necesitas una fecha necesitas pedir memoria, o defines un montón de métodos que trabajen directamente con un entero… y te buscas la vida luego para averiguar cuándo un entero es un número de verdad o está representando una fecha.

Por supuesto, hay otra posibilidad: permitir modificaciones sobre las instancias de tu clase Java. Pero así es menos elegante y te arriesgas a todo tipo de errores. Y, de todas maneras, si necesitas crear 10.000 fechas, tienes otros tantos objetos ocupando memoria dinámica.

El segundo caso

Es más complicado explicar el segundo caso, por lo que voy a recurrir a un ejemplo en uno de mis proyectos: necesitaba un tipo para representar matrices. Las operaciones sobre ellas no formaban parte de la ruta crítica para la velocidad del código, pero la transformación de un vector por una matriz sí era crítica. Además, iba a necesitar muchas instancias de matrices.

Mi solución fue declarar la matriz como una estructura de sólo lectura. No se trata de un tipo pequeño, pues cada una necesita nueve números flotantes de doble precisión. Pero de esta manera ahorré memoria y, muy importante, una indirección innecesaria cada vez que tenía que transformar un vector.

El hacer que el tipo sea de sólo lectura es importante en estos casos, sobre todo si quiere declarar operadores. Mi multiplicación de matrices, por ejemplo, se implementa mediante un operador:

public static Matrix operator *(in Matrix m1, in Matrix m2){}

Si no utilizo los modificadores in en los parámetros, las matrices se pasan por copia. Pero si utilizo in y el tipo no es de sólo lectura, me sigo arriesgando a que el compilador haga una copia preventiva de la matriz, porque al fin y al cabo, in sólo significa que el operador no va a modificar el parámetro en su implementación. Es un poco raro, pero es lo que hay.

Hay que tener en cuenta, además, que en un método normal puedo pasar parámetros mediante ref, pero esto no es posible para un operador.

Un caso más

En mi código, por motivos históricos, hay un tercer caso intermedio: el de los vectores. Mis vectores no son de sólo lectura: quizás sería recomendable, pero me da pereza rescribir todo el código y hacer pruebas para comprobar que todo va mejor. Sin embargo, hago uso profuso del modificador in con vectores pasados como parámetros. ¿Cómo evito el desastre de la copia preventiva? He aquí la respuesta:

public readonly Vector Scale(in Vector factor) =>
    new Vector(X * factor.X, Y * factor.Y, Z * factor.Z);

C# permite declarar métodos con el modificador readonly, para garantizar que el método no modifica campos de la estructura. De este modo, si un método que recibe un vector como parámetro in ejecuta el método Scale u otro método de sólo lectura, el compilador evita crear una copia defensiva del vector.

Más novedades

Hay muchas más novedades en las últimas versiones de C# que tienen que ver con las estructuras (ref struct y ref readonly, por ejemplo), pero en esta entrada me he limitado a tratar algunas de las características que ayudan a la mejor generación de código nativo.