Lo que está dentro NO es como lo que está fuera

El título puede sonar a chino (o a título de peli porno), pero en realidad estoy parodiando uno de los principios de la Hermética: lo que está arriba es como lo que está abajo. Vale, también suena a chino... Lo que quiero decir, en primer lugar, es que hay nueva "píldora orientada a objetos":

• Si define operadores sobre estructuras, vigile el tamaño de las instancias.

Escribo esta nota porque quiero ampliar un poco la explicación, describiendo lo que hace Freya en estos casos. La técnica, en realidad, corresponde a un principio de optimización más general:

• No hay por qué tratar los usos internos de un recurso, desde el mismo módulo que se compila con el recurso, de la misma manera que los usos externos, desde fuera del módulo compilado.

... y de ahí viene el título.

Cuando el compilador de Freya encuentra un operador que actúa sobre estructuras que ocupan mucho espacio, define tentativamente un método interno paralelo, con el mismo "texto" que el operador, pero con un prototipo diferente. Este método sólo pasa a formar parte del código compilado si luego es utilizado internamente por el compilador. En ningún caso se permite que el método sea utilizado desde fuera del módulo, aunque siempre será posible localizar el método con la ayuda de la reflexión.

Si el compilador localiza una llamada al operador en el mismo módulo donde se define éste, incrementa el contador de usos del método paralelo y convierte la llamada al operador en una eficiente llamada al método auxiliar.

Cuando empezaron a aparecer los libros sobre .NET, algunos autores plantearon el problema de si merecía la pena introducir algún tipo de optimización en los compiladores para la plataforma, teniendo en cuenta la existencia de un compilador JIT. Creo que ejemplos como éste demuestran que sí merece la pena, aunque los casos de optimización sean algo diferentes a los tradicionales. Un problema con este tipo de asimetría entre los usos internos y externos de un recurso es la duplicación inevitable de recursos, que trae dos problemas:

• El compilador JIT debe trabajar más, al existir más código que debe ser traducido. Si nos excedemos, podemos ralentizar la carga del módulo o ensamblado.
• Si nos pasamos con el código "paralelo", también haremos daño a la memoria caché del procesador.

En estos momentos, el compilador de Freya no contiene un mecanismo de protección para este problema potencial, pero tenemos planes de añadir un "monitor de complejidad" en algún momento del desarrollo. Si la cantidad de código generador adicional sobrepasa cierto límite que habrá que determinar de manera experimental, este monitor elegirá las optimizaciones más "importantes" y eliminará las que considere prescindibles.

¿Alguien pensaba en serio que todo estaba dicho en el área de los compiladores?